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COLLABORATIVE CREATION, EDITING, REVIEWING, AND SIGNING OF 
ELECTRONIC DOCUMENTS 



Collaborative Creation, Editing, Reviewing, and Signing of 
Electronic Documents 
Cross-Reference to Related Applications 
Background of the Invention 
Field of the Invention 

The present invention relates generally to electronic documents, and more particularly, to an Internet 
facility for the collaborative creation, editing, reviewing and signing of electronic documents. 

Identification of Copyright 

A portion of the disclosure of this patent document contains material that is subject to copyright protection. 
The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or 
the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but 
otherwise reserves all copyright rights whatsoever. 

Description of the Background Art 

E-commerce, and more recently e-business, is rapidly becoming the watchword for businesses in this 
millennium. The appeal of a completely paperless transaction isobvious-reduced storage costs; instant 
global access to transaction data; the creation of an audit trail; lower transaction costs and the merging, 
filtering, and mining of data. Not only will businesses benefit from paperless transactions, but also a 
number of other institutions, such as courts, financial institutions and government agencies. 

A few problems need to be addressed, however, before widespread acceptance of paperless transactions 
is possible. First, there is a need for an Internet facility or"virtualspace"that enables multiple users to 
share, edit and review documents, wherein each user may be located at different geographical locations. 
Second, there is a need for a virtual"signing roonrT'that enables real-time access to each of the documents 
that must be signed to complete a transaction. Finally, there is need to monitor and store actions 
performed on the documents in order to monitor the transaction for completeness and later legal review. 

The problem of enabling multiple users to share, review and edit documents is a key problem for 
establishing a forum for creating binding legal relationships between geographically diverse entities. For 
example, a company in Utah may wish to receive funding from several venture capitalist firms in 
California, Florida and New 

York. As these agreements are often hotly contested, the ability to review the edits of each of the other 
parties involved in the transaction, as well as the ability to further modify the documents to bring them in 
line with expectations, is an essential requirement. In order to avoid the creation of conflicting documents 
in most transactions today, there is often a lead party that may attempt to represent these diverse interests 
and serves as the document"holder". The document is often e-mailed to each party whenever any 
revisions are made in spite of the fact that not every party may be affected by or interested in the 
revisions. More importantly, the lead party may not accurately represent the interests of the junior parties; 
longer delays may thus result due to individual edits performed by each party separately, each of which 
must then be reviewed separately by each of the other parties and their respective legal counsel. By the 
time each party's counsel gets anopportunity to review the document, another party in the transaction may 
have revised the document. The traditional way to avoid these difficulties is to simply assemble all of the 
parties together in a physical meeting room at a single geographical location. Such an approach may be 
unfeasible or expensive (due to time and travel cost), and may even result in termination of the deal as a 
result of the excessive burdens associated with imposing such meetings on all parties involved. 

A second problem associated with conventional methods for transacting business is the difficulty in 
reviewing and agreeing to each of the deal documents involved in the transaction in a timely manner. In a 
corporate acquisition, for example, there are often several separate agreements that may impact an 
executive of a company being acquired. The agreements may include a stock transfer agreement, an 
assignment of intellectual property, an employment agreement and the primary acquisition agreement. 
Each of these agreements must be signed before the deal is complete. It is standard practice today to fly 
each of the interested parties out to a single geographical location and to use multiple legal assistants to 
track down each party and await the review and signature of each party. This process is timconsuming, as 
each party that signs the agreement must review the agreement and, since several parties are often 
required to sign the same agreement, each must have individual possession of the agreement during 
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review. Additional problems ensue when last minute revisions are made to the document prior to a public 
announcement resulting in a frantic signing session. 

This process can also result in errors and/or omissions in the signed documents. A required party may not 
be available at the time of the meeting. The wrong party may inadvertently sign a document, or the wrong 
version of a document may be.signed by one or more .of the parties. . - „». ■• 

In addition, since each party may need to sign off on a separate set of documents, it is often difficult to 
ascertain whether all of the required signatures have been properly captured on the correct versions of the 
documents. In order to minimize such errors, and in order to ensure that each of the agreements has been 
properly executed, a time-consuming and expensive audit of the agreements is often performed. 

What is needed, then, is a system and method for creating a virtual signing room that enables parties to 
review and edit multiple agreement documents without requiring that the parties be physically present at 
the same location. What is further needed is a system and method for enabling different individuals to 
review and sign each of the agreements pertaining to their role in the transaction. What is further needed 
is a document processing system that provides an audit trail for the signing room that confirms that each 
party has signed the necessary documents and records each signature accordingly for later verification. 
Finally, what is needed is a system and method for enabling multiple parties to review, modify, and 
execute multiple agreements, thatminimizes the above limitations and problems of the prior art, reduces 
costs and burdens, and improves accuracy. 

Summary of the Invention 

The present invention solves the foregoing problems by providing a virtual signing room that provides real- 
time access to agreement documents, regardless of geographical locations of the various parties involved, 
and provides a complete audit trail for all activity occurring in the virtual signing room. The present 
invention provides quick and easy access to all documents to be reviewed and/or signed by each party, as 
identified by each party's respective role, and also ensures that documents are signed in the proper order 
as defined by various commercial standards or other requirements. In a preferred embodiment, the virtual 
signing room of the present invention advantageously uses document-driven processing of digitally 
signed, electronic documents, as disclosed in co-pending U. S. Patent Application Serial No. 09/335,443, 
to help achieve the above-listed objectives. 

In one aspect of the invention, a virtual signing room is provided that provides real-time access to 
agreement documents. In one embodiment, the signing room is a private room that can only be accessed 
by specified individuals, such as the parties to the transaction. The system uses standard authentication 
technology, such as digital certificates or biometric devices, to verify a party's identity prior to transmission 
of the web page or other physical manifestation of the signing room. In one embodiment, the invention 
includes a signing role identifier for associating the identity of the party with one or more signing roles, a 
document management system for retrieving each of the necessary documents and providing access to 
the documents accordingly, and a deal management module for ensuring that the proper signing 
sequence is followed and that each of the necessary signatures is received. 

In another aspect of the invention, the document management system includes a document privilege 
module that defines privileges for each of the parties, such as permission levels for viewing, editing and 
modifying the document or specified portions of the document. 

In another aspect of the invention, the document management system includes a notification module for 
notifying various parties of revisions to one or more of the documents. Such notification may be provided, 
for example, upon entry into the virtual signing room (e. g. by display of a dialog box, or an on-screen 
indicator displayed adjacent to recently-modified documents), and/or it may include an email notification to 
the party. Thus, for example, a party may be notified by e-mail when portions of the documents identified 
as critical, such as portions affecting price or term of the agreement, are modified but may only be notified 
upon entry into the virtual signing room when less critical terms are modified. The party may designate 
which forms of notification are desired for various types of document modifications. 

In another aspect of the invention, the document management module includes a document revision list 
that provides a complete record of the transaction. 

This might include, for example, a listing of each of the revisions made to the document, the date and time 
of each revision, and the authenticated party responsible for the revisions. This information could be used 
during negotiations over the agree ment itself or could be used after the fact to help define the 
parties'intent at the time of the transaction. 
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In another aspect of the invention, a deal management module is provided that manages the steps 
associated with completing the deal and monitoring the performance of each of the parties to the deal. In 
one embodiment, the deal management module includes a list of items that must be accomplished to 
complete the transaction. In the simplest case, this list might include, for example, a requirement that the 
entry of contact information into a field of the document is completed and the signature of a party is 
applied. In a more complex deal, Xhe list, might include the requirements, that several. differ^t agreements-. >,.. 
are signed at various times (arid in a particular order) during the transaction. For example; the deal may ... 
be initiated with the application of the signature to a non-disclosure agreement and end with application of . 
the signature to the final acquisition agreement. Furthermore, revisions in the agreements can be used to 
trigger new items on the list as necessary to effectively complete the transaction. 

Brief Description of the Drawings 

Figure 1 is a functional block diagram of a system for digitally signing an electronic document according to 
one embodiment of the present invention. 

Figure 2 is a physical block diagram of a system for digitally signing an electronic document according to 
one embodiment of the present invention. 

Figure 3A is a block diagram of an Internet facility for reviewing, editing and signing electronic documents 
according to one embodiment of the present invention. 

Figure 3B is a block diagram showing a four-tier architecture for implementing one embodiment of the 
present invention. 

Figure 3C is a block diagram showing a four-tier architecture including an E 
Cabinet for implementing one embodiment of the present invention. 

Figures 4A-4B are screenshots of a sample system for digitally signing an electronic document according 
to one embodiment of the present invention. 

Figures 5A-5B depict an example of an agreement document in paper form. 

Figures 6A-6B depict an example of a screen display of an agreement document. 

Figure 7A is a flowchart illustrating the process of entering a virtual signing room according to one 
embodiment of the present invention. 

Figure 7B is a flowchart illustrating the process of reviewing and signing a document according to one 
embodiment of the present invention. 

Figures 8A-8B depict an example of a screen display of a completed and digitally signed agreement 
document. 

Figure 9 is an example of a screen display of an ACH Authorization Form. 
Figures10A-10B depict an example of a screen display for a Change and Enrollment Form. 
Figure 11 is an example of a screen display for passphrase entry and key generation. 
Figure 12 is an example of a screen display for private key retrieval. 

Figure 13 is a flowchart showing a document signing method according to one embodiment of the present 
invention. 

Figure 14 is a system block diagram of one embodiment of a document management flow process in a 
signing room implemented according to the present invention. 

Figure 15 is a system block diagram of one embodiment of a document management flow process in a 
disclosure room implemented according to the present invention. 

Figure 16A is a flowchart showing a signing room logon and entry method according to one embodiment 
of the present invention. 

Figure 16B is a flowchart showing a signing room admittance procedure according to one embodiment of 
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Figure 16C is a flowchart showing an account termination method according to one embodiment of the 
present invention. 

.Kigure .t7.is.aflo collection methbd;according to one .... ~ 

embodiment of the present invention. '. 

Figures 18A-D are screen shots showing an example of a signing room according to one embodiment of 
the present invention. 

Figure 19 is a flowchart showing a deed recording method according to one embodiment of the present 
invention. 

Figure 20 is a block diagram showing a mortgage signing room architecture according to one embodiment 
of the present invention. 

Figure 21 is a site architecture diagram of a mortgage signing room according to one embodiment of the 
present invention. 

Detailed Description of the Preferred Embodiments 

A preferred embodiment of the invention is now described with reference to the Figures, where like 
reference numbers indicate identical or functionally similar elements. The particular sequence of steps 
shown in the various methods described below may be performed, for example, by a computer or set of 
computers following a set of instructions specified in software code. One skilled in the art will recognize 
that other mechanisms and implementations for performing such methods may also be employed. 

Referring now to Figure 1 , there is shown a functional block diagram of a system 100 for digitally signing 
electronic documents 102. Although this system will be used to describe one embodiment of the present 
invention, other document processing systems could also be used to implement the virtual signing room. 
As described hereafter, each document 102 is preferably encoded using a markup language, such as the 
February 1998 W3C Recommendation Extensible Markup Language (XML) 1.0, although the invention is 
not limited in that respect. For example, the standard generalized markup language (SGML, ISO 8879) or 
another markup language could be used without departing from the spirit of the invention. Preferably, the 
document 102 is indexed for full text searching, and the document data within tagged fields are indexed 
for field searches. The indexing allows a user to easily perform document queries using techniques well 
known to those skilled in the art. 

The document 102 may represent any of a number of legal or commercial instruments, such as sales 
contracts, licenses, non-disclosure agreements, patent applications, court pleadings, mortgages, and the 
like. Appendix A is an example of a document type definition (DTD) in the context of an electronic court 
filing system. 

Appendices B and C show an example of an XML-encoded document corresponding to the agreement 
document depicted in Figures 6A-6B. Appendix B shows the document in its initial state; Appendix C 
shows the document after it has been completed and digitally signed. It should be recognized that a wide 
variety of applications, instruments, and/or document types may be provided within the scope of the 
present invention. 

Briefly, the principal components of the system 100 include a role identifier 104, a parser 106, and a 
signing module 108. In one embodiment, the foregoing components are implemented as software modules 
running on a conventional personal computer employing, for example the MicrosoftO Windows 98 
operating system and anlntelQ3 Pentium microprocessor, although other implementations are possible. 
For example, the components could be distributed among a plurality of computers within a network. 
Alternatively, the components could be implemented as hardware devices within an embedded system. 
Although the components are described herein as separate functional units, those skilled in the art will 
recognize that various components may be combined or integrated into a single software application or 
device. 

The role identifier 104 determines the role or capacity in which a signer is to digitally sign the electronic 
document 102. Unlike conventional systems which are limited to the signing of an entire document by a 
single person in a single role or capacity, the present invention allows multiple individuals to sign different 
portions of the document 102 in multiple different roles or capacities. Thus, the present invention enables 
the signing of complex, real-world documents. 
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In one embodiment, the role identifier 104 is implemented as a Web browser, such as the Microsoft 
Internet Explorer, available from Microsoft Corporation of 

Redmond, Washington. Preferably, the role identifier 104 receives input from the signer to determine the 
signer's identity and/or role. As discussed in greater detail below, the input is obtained using conventional 
input mechanisms such as pulldown menus, radio buttons, text entry boxes, and the like. 

In one embodiment, the role identifier 104 includes an authenticator 110, which is used to authenticate the 
signer's identity, as well as the signer's authorization to sign the document 102 in the specified role. 
Although a variety of authentication systems exist, a public key cryptosystem is preferably used to 
authenticate the signer, as described hereafter. In one embodiment, the authenticator 1 10 is implemented 
as a"plug-in"module to a conventional Web browser. Although the authenticator 1 10 is illustrated herein as 
a component of the role identifier 104, it should be recognized that the authenticator 110 could be 
implemented as a separate functional unit. 

Coupled to the role identifier 104, the parser 106 parses the document 102 to identify the portion to be 
signed by the signer, i. e.the"to-be-signed"portion. In one embodiment, the parser 106 is an XML parser 
adapted to parse an XML-encoded document 102. As described in greater detail below, the parser 106 
identifies within the document 102 a"to-be-signed"tag 1 16 or other delimiter for indicating a portion of the 
document 102 to be signed by the signer in the specified role or capacity. The document 102 may include 
a plurality of such tags 116 corresponding to the plurality of signers and roles. In addition, the parser 106 
may be used to identify one or more"accessib!e-by"tags 120 within the document 120, as described in 
greater detail hereafter. 

In a preferred embodiment, XML is used because it may be parsed using a relatively simple parser 106. 
However, as noted above, SGML or another markup language could be used without departing from the 
spirit of the invention. In one embodiment, the parser 106 is a commercially available XML parser, such as 
the 

XML parser available from Microsoft Corporation. However, a custom-designed parser 106 could also be 
used within the scope of the present invention. 

Coupled to the parser 106, the signing module 108 applies the signer's digital signature to the identified to- 
be-signed portion of the document 102. In one embodiment, the signing module 108 applies the digital 
signature using the RSA Public 

Key Cryptosystem, available from RSA Data Security, Inc. of San Mateo, California, although the invention 
is not limited in that respect. The RSA Public Key Cryptosystem is well known to those skilled in the art, 
and has become a de facto standard for cryptographic communications and digital signatures. In one 
embodiment, the signing module 108 is implemented asa"plug-in"module to a standard Web browser, 
although other implementations are possible without departing from the spirit of the invention. 

In one embodiment, the signing module 108 includes a message digest calculator 1 12 for calculating a 
message digest for the to-be-signed portion. As noted above, the message digest is a number or code that 
represents the to-be-signed portion of the document 102. Preferably, the message digest is calculated 
using a oneway hash function, such as the Secure Hash Algorithm (SHA) or Message Digest (MD5), 
whereby any change to the message will result in a different calculated message digest. SHA was 
developed by NIST as specified in the SHS (Secure Hash Standard). The algorithm takes a message (less 
than264 bits of length) and produces a 160-bit message digest. MD5 was developed by RSA and takes a 
message of arbitrary length and produces a 128-bit message digest. Although the message digest 
calculator 1 12 is illustrated herein as a component of the signing module 108, it should be recognized that 
the calculator 112 could be implemented as a separate functional unit. 

The signing module 108 also includes an encryptor 1 14 for encrypting the message digest with the 
signer's private key. The encrypted message digest is referred to herein as a digital signature 118. In one 
embodiment, the digital signature 118 is stored within the document 102 and associated with the portion of 
the document 102 that was signed. Alternatively, the digital signature may be stored with other document 
audit information for later verification. Although the encryptor 1 14 is illustrated herein as a component of 
the signing module 108, it should be recognized that the encryptor 114 could be implemented as a 
separate functional unit. 

Referring now to Figure 2, there is shown a physical block diagram showing the components used to 
implement the functionality of Figure 1, according to one embodiment of the present invention. A central 
processing unit (CPU) 202 executes software instructions and interacts with other system components to 
perform the methods of the present invention. A storage device 204, coupled to the CPU 202, provides 
long-term storage of data and software programs, and may be imple mented as a hard disk drive or other 
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suitable mass storage device. In one embodiment, the storage device 204 stores a plurality of documents 
102 to be signed. 

A network interface 206, coupled to the CPU 202, connects the system 100 to a network (not shown), 
such as the Internet. Such connection is implemented according to techniques that are known in the art. A 
--'display device 208,-^upled^tQ the//----'' . - y-" : - ;. ; v : « ^ •<.']} ■>:>•••• ' > ■ -. ;: V ; 
: CPU 202, displays text and graphics under the cohtrol of the CPU 202. An input device 210, coupled to 
the CPU 202, such as a mouse or keyboard, facilities user control of the system 100. A"smartcard"reader 
21 1 , coupled to the CPU 202, facilitates access to a smartcard for authentication purposes, as described 
in greater detail below. 

An addressable memory 212, coupled to the CPU 202, stores software instructions to be executed by the 
CPU 202, and is implemented using a combination of standard memory devices, such as random access 
memory (RAM) and read-only memory (ROM) devices. In one embodiment, the memory 212 stores the 
above-described document 102 and software modules, including the role identifier 104, parser 106, 
signing module 108, authenticator 110, message digest calculator 112, and encryptor 1 14. 

In one embodiment, the memory 212 also includes an operating system 214 for managing and providing 
system resources to the above-mentioned software modules. 

Preferably, Windows 98, available from Microsoft Corporation, is used, although a variety of other 
operating systems 228, such as Windows 2000, MacOS 8, UNIX, or Linux may be used within the scope 
of the present invention. 

Referring now to Figure 3A, there is shown a block diagram that illustrates one embodiment of an Internet 
facility for reviewing, editing and signing electronic documents according to the present invention. In one 
embodiment, the invention includes a virtual signing room 300 implemented as a web page using XML 
technology. Alternatively, other markup languages could be used. The signing room 300 comprises three 
separate logical modules: a document management module 310; a party-to-document mapping module 
320; and a deal management module 330. 

The document management module 310 serves to manage the documents associated with the deal or 
transaction. Module 310 also monitors and maintains an audit trail for any revisions or alterations made to 
the documents. In one embodiment, the document management module 310 establishes access rules 
fordetermming to what extent each party in the deal room has permission to view and/or modify each 
document. 

Once a party is authenticated and enters the signing room, the document management module 310 
retrieves the documents that the party has permission to view by making calls to the document-to-party 
mapping module 320. As described above, for each document, permissions may be granted for the entire 
document or for a portion of the document associated with the authenticated party. Furthermore, the 
document management module 31 0 determines whether any revision privileges exist for the party with 
respect to retrieved documents. Again, such privileges may be defined with respect to an entire document 
or may only apply to a portion of the document. For example, one party may have the ability to modify the 
correspondence address used in the agreement or the spelling of their own name but may not be 
permitted to make any revisions to other material terms in the agreement. 

In one embodiment, the document management module 310 includes an audit module 315. The audit 
module 31 5 tracks and stores all revisions 318 to the documents made by each party. By storing the 
revisions 318 to the documents, the audit module provides a roadmap beginning with the initial version 
316 of the agreement and ending with the final version incorporating revisions 318, thereby enabling better 
interpretation of the resulting agreement by the parties. Furthermore, the functionality of the audit module 
315 can be used in conjunction with a notification module 317 to provide notification to the parties of any 
revisions to the documents. 

In one embodiment of the invention, the notification module 31 7 may be used to notify different parties of 
revisions to one or more of the documents. Such notification may be provided, for example, upon entry 
into the virtual signing room 300 (e. g. by display of a dialog box, or an on-screen indicator displayed 
adjacent to rcently-modified documents), and/or it may include an e-mail notification to the party. Thus, for 
example, a party may be notified by e-mail when portions of the documents identified as critical, such as 
portions affecting price or term of the agreement, are modified but may only be notified upon entry into the 
virtual signing room when less critical terms are modified. In one embodiment, the party may designate 
which forms of notification are desired for various types of documentmodifi- cations. 



http://v3.espacenet.com/textdes?DB=EPODOC&IDX=EPl 1 775 1 7&QPN=EP 1 1 775 1 7 



1/28/2004 



esp@cenet description view 



Page 7 of 31 



In one embodiment, the party-to-document mapping module 320 includes a role identifier 104 for 
generating and maintaining a map 322 assigning a role for each party, and a map 324 for associating 
each role with one or more documents. As noted earlier, the role identifier 104 receives input from the 
signer to determine the signer's identity and/or role. In one embodiment, the role identifier 104 uses 
conventional input mechanisms such as pull-down menus, radio buttons, or text entry boxes to receive 
^nput specifying a role- The presehWnyention thus facilitates rnian agementpf. document pnyilegesun the: - j 
context of a complex transaction where each piirty may be. associated with multiple roles. For example,' an 
executive in a company may serve as a board member, a shareholder, an employee and an inventor. By 
providing access to documents based on a role, the executive can review each agreement separately by 
selecting each role in turn. Alternatively, the party may wish to simply receive all documents that are 
associated with each of the roles that the party has been assigned. 

For example, in one embodiment as illustrated in Figures 4A and 4B, the signer's role is specified by 
means of a pull-down menu 402. Likewise, in certain embodiments, the identity of the signer may be 
obtained from a tt cookie"or from network login information. However, it should be recognized that the 
signer's identity could be separately specified. 

Once a role has been specified, the party-to-document mappin tify each to-be-signed tag 1 16 contained 
therein. As noted earlier, each to-be-signed tag 1 16 indicates a role of a signer. Thus, an index (not 
shown) of documents 102 and roles may be created, which may then be used by the role identifier 104 to 
generate a list 404 of documents 102 for a specific role. This enables the addition of documents at a later 
time without requiring an administrator to recreate a new list with each new document. 

A deal management module 330 is also provided for managing a deal completion list 332 of items that 
must be accomplished to complete the deal. In the simplest case, this list might include, for example, a 
requirement that certain contact information be entered in a field of the document and that a signature be 
applied, or that two signatures be applied to a document in a particular order. In a more complex deal, the 
list might include, for example, application of one or more signatures to several different agreements at 
various times during the agreement. For example, the deal may be initiated with application of a signature 
to a non-disclosure agreement and end with application of a signature to a final acquisition agreement. 

In one embodiment, a next step module 334 is provided that monitors and attempts to complete the next 
step in the deal. This might involve, for example, automatically sending an e-mail message to the party 
that is responsible for the next step in the deal. Alternatively, the next step at a given stage of the deal 
may involve, for example, retrieving a document from another server or generating a summary of the 
agreement; the next step module 334 interactively makes requests as necessary to complete the 
appropriate task. 

Additionally, the deal management module 330 may add new items to the list responsive to revisions in 
one or more of the agreements in order to effectively complete the new transaction. The application of a 
signature to a project agreement, for example, may dictate that a project description be added to the list to 
complete the transaction. 

Referring now to Figure 3B, there is shown a four-tier architecture as may be used for implementing one 
embodiment of the present invention. The four tiers include, for example: 

* Client tier 341 , such as a conventional browser; 

* Presentation tier 341, including functionality for authentication, sign 
ing room, E-Cabinet, and administration, as described in more detail 
below; 

Business logic tier 343, including functionality, such as a Virtual File 
Clerk (described in more detail below) for processing requests and per 
forming other business functions; and 

Persistent storage tier 344, including database (RDBMS) and document 
store. 

Tiers interact with one another to perform the functionality of the networkbased application, as is known in 
the art. In one embodiment, the virtual signing room of the present invention is implemented as part of 
presentation tier 341 , along with other functionality. 

Referring now to Figure 3C, there is shown a block diagram illustrating the functional modules of 
presentation tier 342, including authentication 352, signing room 300, and E-Cabinet 352. E-Cabinet 352 
is a presentation-level tier application that provides access to a repository of documents, such as may be 
stored in persistent storage tier 344 (on a database, for example). E-Cabinet 352 may be used, for 
example, to archive documents after completion of a deal or other transaction. Access to particular 
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documents within E-Cabinet 352 may be permitted or restricted based on various characteristics, subject 
to verification of the user's identity. 

Thus, for example, a user would provide a user name, password, and/or additional identity verification 
such as.digital signature and biometrics. The user then selects a role from a list of available roles in 
: \ connection with E J Oabiriet 3.52. E •*'./>■■ . v - •v\-'- ,: ; ■ *:"•■■ . "!■"... -\v : -^ " .. : :v\ 

Cabinet 352 presents the user, via a browser, with a list of documents that are relevant to the uselr and his 
or her selected role. 

In one embodiment, various views and modes of accessing documents may be provided, including a 
search function 353, status report 354 as to selected documents, and hierarchical display 355 of 
documents. Search function 353 may provide, for example, full text indexing and searching, and/or field- 
specific search functionality for documents in the E-Cabinet 352 (which are stored in persistent storage tier 
344 such as a database). Business logic tier 343, such as a virtual file clerk, processes requests made by 
the user, retrieves the appropriate data from persistent storage tier 344, filters the results so that they only 
contain information to which the user has access, and provides the documents for display in client tier 341 . 

One skilled in the art will recognize that the architecture shown in Figures 3B and 3C, and the E-Cabinet 
functionality described above, are merely exemplary, and that other architectures and methods for 
implementing the present invention are possible. 

Referring now to Figure 7A, there is shown a flowchart illustrating the process of entering the virtual 
signing room 300. As an initial matter, the identity of the party attempting to enter the Internet facility or 
signing room 300 is requested 702. 

This might involve user entry of a user name with a password that can be issued to log into all deals 
pending on that server or might involve entering a special code that has been provided to the party for a 
single deal. 

The method continues by authenticating 704 the party for the specified role. 

The authenticator 110 verifies the identity of the party before the party is allowed to sign the document 102 
in the specified role or capacity. If the authentication is unsuccessful, the invention detects and prevents 
the unauthorized access. 

Various forms of authentication may be performed in connection with the present invention. For example, 
public key cryptography offers a particularly secure method for authentication. In one embodiment, the 
party inserts a smartcard encoded with his or her private key into the smartcard reader 21 1 . Smartcards 
and smartcard readers 21 1 are available from a variety of sources, such as Micromodular 
Data Solutions of Santa Clara, California. 

The authenticator 110 uses the private key encoded within the smartcard to encrypt a standard message. 
Thereafter, the authenticator 1 10 attempts to decrypt the message using the party's public key, which may 
be obtained from a public key database or the like using a standard protocol, such as theLightweight 
Directory 

Access Protocol (LDAP), which is part of the X. 500 standards. If the message is sue cessfully decrypted, 
the smartcard is known to contain the private key of the authorized signer. 

For even greater security, the smartcard may contain previously-acquired biometric data of the signer, 
such as digitized fingerprints, voiceprints, facial configurations, iris images, and the like, which may be 
compared with new biometric data obtained at the time of authentication using a biometric data acquisition 
device (not shown). Biometric data acquisition devices are well known in the art and may be obtained from 
a variety of sources. For example, fingerprint identification systems may be obtained from Digital Persona, 
of Redwood City, California. Likewise, 

SAFIink Corp., of Tampa, Florida provides a system for voice, face and fingerprint recognition. IriScan, Inc. 
of Marlton, New Jersey provides a system for iris scanning. 

If the previously acquired data substantially matches the new biometric data (within acceptable tolerances 
for noise and other effects), the party will be declared authentic. In combination with the public key 
authentication system discussed above, the foregoing technique makes the signer's digital signature far 
more reliable and difficult to repudiate than its handwritten equivalent. 

In alternative embodiments requiring a lesser degree of security, the party may provide a pass phrase or 
the like to the role identifier 104, after which the pass phrase is compared against a database of pass 
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phrases for various signing roles. If a match is found, the party is authorized for the corresponding role 
and is allowed to enter the signing room 300. 

Referring now to Figure 7B, there is shown a flow chart illustrating the process of reviewing and signing a 
document. The method begins byobtaining 706 the private key of the signer. As noted earlier, the private 
I •. - toy isojsed for generating the signer's digital signature 11 8 r In the smartcard ernbod jment.descnbed : - \ . ■: . .. . 
above, the signer's priv/ate key is retrieved from the smartcard. Various security rineasures, well known to 
those skilled in the art, may be used to prevent unauthorized access to and retrieval of the signer's private 
key. In the case of the pass phrase embodiment, a private key is preferably stored within the database for 
each pass phrase. When a match is found, the corresponding private key is retrieved from the database. 

After the private key is obtained, the method continues by locating 708 a tobe-signed tag 1 16 within the 
document 102 corresponding to the specified role of the signer. As explained above, the to-be-signed tag 
1 16 is an XML tag used for indicating a portion of the document 102 to be signed. In an alternative 
embodiment, an 

XML attribute is used for the same purpose. The parser 106 parses the document 102 to find the to-be- 
signed tag 1 16 corresponding to the specified role. If the parser 106 is unable to find the tag 1 16, an error 
is preferably generated. 

Thereafter, the to-be-signed tag 1 16 is used to identify 710 the to-be-signed portion of the document 
corresponding to the role of the signer. In one embodiment, each to-be-signed tag 1 16 comprises a 
beginning tag (comprising an identification of a role) and an end tag. For example, a to-be-signed tag 116 
has the following form in one embodiment: 

< TBSignedSiglD="Governor" > 

< /TBSigned > 

The text between the beginning tag and end tag is the to-be-signed portion of the document 102. The use 
of to-be-signed tags 116 allows various portions of a document 102 to be signed by different individuals, 
unlike some conventional systems that are limited to signing an entire document by a single individual. 

After the to-be-signed portion is identified, a check 712 is made whether access to any portion of the 
document 102 is restricted, indicating that the portion should not be displayed to the signer. The ability to 
restrict the viewing of particular portions of a document 102 is advantageous in many contexts. For 
example, an electronically filed court document might include portions that are sealed by a court order, 
while the unsealed portions should still be available to be viewed by the public. 

Similarly, certain agreements may include portions that are not relevant to certain individuals, and thus 
should not be viewed by particular signers. Thus, in one embodiment, access restrictions may be placed 
on the document 102 in order to allow the signer to view certain portions and not others. This is an 
advance over conventional systems in which a digitally signed word-processing or otherwise-encoded 
document must be displayed to the signer in its entirety or not at all. 

As described above, the document 102 may include one or more accessible-by tags 120 for indicating 
access restrictions to portions of the document 102. In an alternative embodiment, XML attributes are 
used for the same purpose. Like the to-besigned tag 116, the accessible-by tag 120 includes a beginning 
tag and an end tag, and the text between the tags is the portion of the document 102 that is 
accessrestricted. Preferably, the parser 106 is used to identify the access-restricted portions of the 
document 102. 

In one embodiment, the accessible-by tag 120 includes an indication of one or more roles, access levels, 
or the like, of individuals who may view the document 102. 

For example, in one embodiment, an accessible-by tag 120 has the following format: < AccessibleBy > 

< ViewModify > < PerslnfoRole="Judge" > < A/iewModify > View > < Perslnfo Role="Plaintiff" > < A/iew > 

< /AccessibleBy > 

In this example, the judge may both view and modify the document 102, while the plaintiff may only view 
the document 102. Preferably, all other individuals would not be able to view or modify the document. 

If, in step 712, it is determined that the document includes access restrictions, the method continues with 
step 714 by preventing unauthorized access to the accessrestricted portions, such as by masking the 
display of, and/or preventing revisions or modifications to, those portions. In one embodiment, one or more 
masked portions may be encrypted using the public key of the person authorized to access those portions. 
As a result, if the signer is the authorized party, only she may use her private key to decrypt and display 
the masked portions. 
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After either steps 712 or 714, the method continues by displaying 716 the document 102, excluding any 
masked portions, to the signer, and accepting any edits or revisions to the portions accessible to the 
signer. This allows the signer to review the document 102 and make any required selections or revisions 
before applying his or her digital signature 118. 

"V ':■ • ■'• After lire document 102 hasrbeeh displaved and edited, the method continues by receiving 7113 from the- : \ ; . 
signer an indication to sign the document 102. this may be accomplished in any of a variety of ways, as 
will be apparent to one skilled in the art. 

For example, the signer may use the input device 210 to click on a"sign now"button or the like. 

Next, the method continues by storing 720 in the to-be-signed portion of the document 102 the date and 
time at which the document 102 is signed. Preferably, the current date and time is read from a system 
clock (not shown) or the like, which is coupled to the CPU 202. The inclusion of a time and date stamp is 
useful for auditing purposes, and for later verification of the validity and applicability of the signed 
document 102, for example in a court or administrative proceeding. By providing date and time stamps for 
individually-signed portions of the documents 102, the present invention provides advantages over 
conventional systems which may not be able to realistically model documents 102 that are signed at 
different dates and times by different individuals. 

In one embodiment, date and time tags are added to the to-be-signed portion, identifying the date and 
time at which the signer signs the document 102. For example, the date and time tags have the following 
format in one embodiment: < date > 01-02-1999 < /date > 
< time > 15: 43: 16.12 < /time > 

By adding the date and time tags to the to-be-signed portion, the tags are digitally signed, so that the 
signer cannot later repudiate the date and time of the digital signature. 

After the date and time are stored, the method continues by calculating a message digest for the to-be- 
signed portion of the document 102. As noted above, this is accomplished in one embodiment using a 
one-way hash function, such as 

SHA or MD5, whereby any change to the message will result in a different calculated message digest. 
Those skilled in the art will recognize that a variety of other hash functions could be used without departing 
* from the spirit of the invention. 

Thereafter, the method continues by encrypting 722 the message digest using the signer's private key to 
generate the signer's digital signature 118. While it is possible to encrypt the whole document 102 without 
departing from the spirit or essential characteristics of the present invention, it is typically not necessary to 
do so, because many documents are non-private except for specific portions that may be masked as 
described above. Moreover, since encrypting a document (such as by public key cryptography, symmetric 
cryptography, or other means) can be relatively slow, it is advantageous tominimize the amount of data 
encrypted. 

After the digital signature 1 18 is created, the method continues by storing the digital signature 118 within 
the document 102. In one embodiment, the digital signature 118 is stored directly after the to-be-signed 
portion, although one skilled in the art will recognize that the signature 118 can be stored at other 
locations. 

In one embodiment, the document 102 includes a signing history portion for storing the digital signature 
1 1 8 of each signer of the document 1 02. The signing history portion may be separately designated by an 
XML tag, such as < Signa- tures > < /Signatures > , and forms a convenient location for storage of 
information indicating which signers have signed the document 102. 

After the digital signature 1 18 is stored, the method continues by obtaining 728 and storing the signer's 
digital certificate. A digital certificate is an attachment to a document 102 that provides additional 
verification that the signer is whom he or she claims to be. An individual wishing to digitally sign a 
document applies for a digital certificate from a Certificate Authority (CA), such as Verisign, Inc., of 
Mountain View, California. The CA issues an encrypted digital certificate containing the individual's public 
key and a variety of other identification information. The CA makes its own public key readily available, 
such as through print publicity and/or via the Internet. Thus, the recipient of an encrypted message uses 
! *-\. £ the CA's public key to decode the digital certificate attached to the document 102, verifies it is issued by 
the CA, and then obtains thesender's public key and identification information held within the certificate. 
The recipient thus obtains some assurance that the signer is whom he or she claims to be. In one 
embodiment, the ANSI X. 509 standard is used for such digital certificates in connection with the present 
invention. 
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In one embodiment, the signer's digital certificate is obtained from the signer's smartcard, as discussed 
above. In alternative embodiments, the certificate may be obtained from a database after the signer is 
authenticated with a pass phrase or the like. The digital certificate is preferably stored in the document 102 
near the associated digital signature 1 18. In one embodiment, the digital certificate is identified within the 
.document.1p2 by ■. , a<-€ert>x/Cj5rt>.tefl/\ / ^---V" < .'- 

After the digital certificate is stored, the method continues by displaying 730 a visual indication of the 
signer's digital signature 1 18 in conjunction with the display of the document 102. Any of a variety of 
techniques may be employed. For example, a digitized version of the signer's handwritten signature (not 
shown) may be applied to the document 102. Likewise, in appropriate situations, a graphical seal (not 
shown) could be displayed. This may be particularly appropriate, for example, in the case of a"digital 
notary", who may perform a similar function as a notary public by verifying a signer's digital signature and 
digital certificate with a CA. Moreover, an 

ASCII or Base 64 representation (not shown) of the digital signature 118 could also be displayed. Other 
representations and indications are also possible, such as graphical overlays and the like. After the visual 
indication is displayed, the method of Figure 7B is complete. 

The present invention also facilitates collaborative document editing by remote-located parties. Previously 
stored revision privileges associated with a party are retrieved, and revisions are permitted according to 
the level of privileges. In some situations, a party may only have rights to modify a portion of the 
document. 

Any number of conventional locking mechanisms may be employed to prevent modifications or revisions 
to document data. For example, text fields may be marked with'Yead only"attributes, and text entry fields, 
pull down menus, and radio buttons maybe"grayed out"to prevent modifications to the document 102 
using techniques well known to those skilled in the art. 

If a party wishes to modify the document, the audit module 315 may be initiated to track the revisions and 
to record the party's identity accordingly. Additionally, as described above with reference to Figure 3A, the 
audit module 31 5 verifies whether any notifications should be transmitted to one or more of the other 
parties to the agreement. If so, the audit module 315 performs the action associated with the type of 
revision. For example, if a field has been tagged as"critical" t then an e-mail message may be immediately 
transmitted to one of the parties. 

Referring now to Figure 20, there is shown a block diagram depicting a mortgage signing room 
architecture according to one embodiment of the present invention. For illustrative purposes, the block 
diagram of Figure 20 shows the various parties and components that may interact with one embodiment of 
the present invention to implement a mortgage-related transaction. As can be seen from the Figure, 
signing room 300 forms a central location for access to and modification of various documents, including 
for example, documents to be recorded 2102, title insurance 2104, mortgage closing documents 2108, 
certificate validations 2109, appraisals and certificates 21 1 1 , and notarizations 21 12. Signing room 300 
also provides amechanism for initiating and managing electronic fund transfers 2110, such as between a 
party and a bank 2008, as described in more detail below. 

Various parties interact with the signing room 300 to create, modify, and/or sign any or all of the above 
documents, or to supply support services. Such parties include, for example, a county recorder 2002, title 
company 2004, mortgage company 2006, digital certificate authority 2007, bank 2008, appraisers and 
inspectors 2009, and notaries 2010. Additional parties involved in the transaction, such as the county 
assessor 2001 , the Internal Revenue Service 2003, lender 2005, and the like, may also interact with 
signing room 300 or may instead interact with other parties in a conventional manner, in connection with, 
for example, tax assessments and liens 2101, federal tax liens 2103, loan documents 2107, and signed 
loan documents 2106. The title company 2004 and county recorder 2002 may also share research 2105, if 
de sired. One skilled in the art will recognize that many other parties, interactions, and documents may be 
associated with or connected with a transaction implemented by the present invention. 

In one embodiment, key parties to the transaction, such as abuyer's real estate agent and/or attorneys 
2104, borrower 2105, and seller's real estate agent and/or attorneys 2106, access signing room 300 via 
a"portal"website 201 1 over the 

Internet 2012. A conventional browser may be used for such interaction with the system of the present 
invention. Additional parties, such as the buyer 2013 and the seller 2017, may also interact with the 
present invention, or may be represented by parties 2014 and 2016. 

Referring now to Figure 21, there is shown a site architecture for a mortgage signing room 300 according 
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to one embodiment of the present invention. The site architecture of Figure 21 may be implemented, for 
example in a web site as may be accessible over the Internet. Signing room 300 contains several sections 
and areas for implementing the systems and methods of the present invention, including for example: 
Administration 2201 : Includes functionality for setting up an account, 
identifying parties and roles, defining, workflow, and transferring in 

: .doGument^^ v^v'*- V"t*"Y" : v ": Vs "-/ ; *?"'-i s ^' " ■ Y" v: "v/'V/- : : " * ^ V- 

Editing' 2202: Includes functionality foroperiihg documents, creating . 
virtual copies of documents, making revisions and changes, and initiat 
ing new versions; Verify 2203: Includes functionality for identifying documents to be 
verified, checking certificates and a Certificate Revocation List (CRL), 
and verifying by public key; 

Closing 2204: Includes functionality for monitoring application of sig 
natures to documents, advising parties of the next requirements in the 
transaction, verifying signatures as documents are signed (in conjunc 
tion with verify 2203 area), transmitting deeds and mortgage to county 
recorder, sending documents to all relevant parties, disbursing funds, 

and archiving communications to database or CD-ROM;* Archive 2205: Includes functionality for 
archiving, verifying, indexing, 

compressing, retrieving by search, and the like; 'Signature 2206: Includes functionality for presenting 
unsigned docu 

ments by e-mail, identifying the sender, requesting signature, and ap 
plying signature; 

Certification 2207: Includes functionality for applying for a digital cer 

tificate, selecting a security level and/or strategy, issuing thecertifi- 

cate, filing the security level and/or strategy, and sending the certifi 

cate to the party; andNotarization 2208: Includes functionality for presenting a document, 

identifying the party, acknowledging the digital signature and/or no 

tarizing the signature. Such techniques are described, for example, in 

U. S. Patent No. 5,872,848, for"Method and apparatus for witnessed 

authentication of electronic documents/'issued February 16,1999, the 

disclosure of which is incorporated herein by reference. 

Referring now to Figures 5A-5B, there is shown an example of an agreement document 500 in paper form 
according to the prior art. Various entry fields 501 and signature fields 502 are provided for manual entry 
of information and signatures. 

The document is divided into several sections 503-51 1 , each containing various types of information and 
fields 501 and/or 502. In addition, terms and conditions 512, as well as application instructions 513, are 
provided, as may appear on the back of the printed copy of document 500. 

As can be seen from the example of Figures 5A-5B, some sections of document 500 may not be 
applicable or relevant to some parties to the agreement, or may be more suitable for completion and/or 
signing at different times than other sections of document 500. For example, placement information 505 
may not be relevant or available at the time the agreement is initially filled in, but may be suitable for later 
completion when such information is known. Also, such information 505 may be more suitably completed 
by a different party than the party responsible for completing the other sections of document 500. 

One disadvantage of paper forms such as that shown in Figures 5A-5B is that such distributed completion 
and signing of the document is cumbersome and difficult to implement satisfactorily. For example, the 
party filling in placement information 505 may see credit card information 508 that has previously been 
filled in, when such information is not relevant to that party. In addition, particular sections of terms and 
conditions 512 may only apply to particular parties, but the paper form does not permit selective"signing 
ofTon such individual sections. 

In addition, supplementary forms or other requirements may not easily be provided or associated with the 
document 500. For example, if an Automated Clearing House (ACH) authorization form is required 
because a third-party credit card is to be used, such a form may inadvertently be omitted because the 
party signing document 500 may not be aware of such a requirement, even though paragraph 514 of 
instructions 513 states that such a supplementary form is required. 

Referring now to Figures 6A-6B, there is shown an example of a screen display 600 of an agreement 
document corresponding to the paper document 500 of 

Figures 5A and 5B. The screen display 600 may be displayed using a conventional browser as is known in 
the art. As can be seen from the screen display 600, many of the problems and limitations associated with 
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paper documents are eliminated or minimized. Various fields 601 are provided for entry of information 
corresponding to fields 501 in document 500. If appropriate, fields 601 only include a subset of fields 501 , 
depending on the particular items of information to be collected from the party viewing the display 600. 
Thus, for other parties providing other items of information, a different set of fields 601 might be displayed, 
corresponding to the items of infprmation being sought. 

Note buttons 604 are provided for accessing or providing additional information as may be relevant to 
fields 601 adjacent to buttons 604. 

Generate keys button 602 provides access to functionality for generating public and private keys, as 
described below in connection with Figure 12. Explain button 603 provides additional information 
regarding the function of button 602. 

Enroll button 605 specifies that the party viewing the screen display 600 wishes to enroll in an auto- 
shipment program. This is an example of an application of the present invention, whereby a button 605 is 
used to activate a secondary form or agreement (described below in connection with Figures10A-10B) that 
is only applicable in certain circumstances. Thus, the additional information to be collected in association 
with the auto-shipment program can be relegated to the secondary form rather than presented in the 
primary form. This helps to make the primary form less confusing, as the party need not be concerned with 
areas on the form that are not applicable to his or her particular situation or specified requests. In the 
example shown, sections 507 and 508 of the paper document 500 of Fig. 5A can beeliminated from the 
primary display 600, since they are only applicable if the user clicks on button 605 to specify an interest in 
the auto-shipment program. 

Similarly, checkbox 606 allows the party viewing the screen display 600 to select whether he or she is a 
nonresident alien. If so, another secondary form (not shown) may be provided to obtain further information 
on such a situation. Likewise, ACH button 607 provides access to another form for collecting ACH data, as 
described below in connection with Figure9Scrolling text box 608 displays the text of the terms and 
agreement. The party indicates his or her assent to the terms, and asserts the accuracy of the provided 
information, by clicking on Sign button 609. As described above, authentication of the signer's identity may 
be verified by whatever means are appropriate. 

Referring now to Figures 8A-8B, there is shown an example of a screen display of a completed and 
digitally signed agreement document. This screen may be provided, for example, when a user or party 
wishes to view a previously signed document or agreement. Fields 801 are populated with data as was 
entered previously in fields 601 of Figures 6A-6B. Note buttons 604 are also provided, enabling access to 
supplemental information regarding various fields 801. Statement 806 provides an affirmative statement 
reflecting the party's entry in checkbox 606. Field 802, showing the credit card number of the party, is 
partially obscured so as to hide sensitive data from the viewer. Depending on the identity of the person 
viewing screen 800, and the degree to which that identity can be verified, fields such as 802 displaying 
sensitive data may beomitted, obscured, or displayed in part or in full. 

Parameters for such display may be specified in advance, if desired. 

A hexadecimal representation of the signer's digital signature 803 is provided, giving the viewer of screen 
800 some assurance that the digital signature has in fact been obtained. In addition, in the example of 
Figures8A-8B, a hexadecimal representation of the certificate 804 corresponding to the signer and 
verifying his or her identity, is also shown. This certificate 804 provides an additional level of certainty as to 
the identity of the signer. One skilled in the art will recognize that many other representations of the digital 
signature and/or certificate may instead be displayed, including for example a simple notification or 
graphical element. 

Referring now to Figure 9, there is shown an example of a screen display of an 

ACH Authorization Form 900. Form 900 may be displayed, for example, when a party indicates payment 
by ACH using button 607 of document 600. In this manner, the additional information 901 sought in form 
900 is only collected when applicable. 

In addition, the particular digital signature that is affixed by clicking on button 902 is applicable to the 
particular fields and text shown in form 900. Thus, the present invention provides amechanism for digitally 
signing portions of documents as applicable or appropriate. In one embodiment, upon signing (by clicking 
on button 902), the party is again presented with document 600 for collection of additional information. 

Referring now to Figures10A-10B, there is shown an example of a screen display for a Change and 
Enrollment Form 1000. Form 1000 may be displayed, for example, when a party indicates that he or she 
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clicks on button 605 (shown in Figure 6A) to begin the process of enrolling in an f, AutoShip"program. One 
skilled in the art will recognize that form 1000 is merely exemplary of a secondary form that is activated by 
user selection of an element of a primary form. 

Additional information 1001 is collected, and the user may select from various options 1002 for the 

AutoShip. program by clicking on checkboxes. A. further option .^ in.the . . . J ; . \\ . 

program is also provided 1003. Payment inforrnation is provided in 1004, and the party 'may digitally sign 

the document by clicking on button 1005. In one embodiment, upon signing (by clicking on button 902), 

the party is again presented with document 600 for collection of additional information. 

As will be apparent to one skilled in the art, the various primary and secondary forms and agreements can 
be presented as applicable to any party or combination of parties. Thus, different types of information may 
be collected from different parties, and some sensitive information may not be displayed to all parties. The 
present invention facilitates such flexibility of document review, access, and execution. 

Referring now to Fig. 1 1 , there is shown a screen display 1 100 for passphrase entry and key generation. 
In one embodiment, the party is presented with screen 1 100 after he or she clicks on button 602 (shown in 
Figure 6A). The party enters a passphrase in input field 1101 and confirms entry in field 1102. Optionally, 
the party may specify a file name and/or path for a file containing the private key in field 1 1 03. The private 
key is preferably stored on removable media, such as a floppy disk, so that it can be stored in a secure 
location; though in alternative embodiments the private key may be stored in fixed media. The party clicks 
on Generate button 1104, and the private key is generated and stored on the specified media, according 
to the file name and/or path specified in field 1 103(if applicable), while the public key is sent to the 
Certificate Authority. 

Once the keys have been generated and stored, the user may be prompted for the location of the private 
key (and asked to insert the removable media, if applicable) when the key is needed for authentication 
purposes, as described below. Additional security and/or authentication measure may also be taken, such 
as asking the user to re-enter the passphrase at the appropriate time. 

Referring now to Figure 12, there is shown an example of a screen display 1200 for private key retrieval. 
In one embodiment, screen 1200 is shown whenever a party clicks a Sign document button or otherwise 
indicates that he or she wishes to digitally sign a document. For authentication purposes, the party is 
asked to insert the floppy disk containing the previously generated private key. If appropriate, the user is 
asked to specify the filename and/or path for the private key in field 1 201 . 

Optionally, the user may be asked to enter a passphrase (previously selected in the example of Figure 11) 
in field 1202. The party then clicks on Sign button 1203 to affix the digital signature to the document. 

Referring now to Figure 13, there is shown a flowchart of a document signing method according to one 
embodiment of the present invention. The flowchart of 

Figure 13 is merely illustrative of a particular method as may apply to the processing of the examples of 
Figures 6A-6B and 8A through 12. One skilled in the art will recognize that other variations and methods 
are possible and applicable to different types of documents in accordance with the present invention. 

Once a document has been initiated and a party has digitally signed the document, the document is 
assigned 1302 a Digital Object Identifier (DOI)-a unique number or other identifier that is used to track the 
document. The digital signature is verified 1303 to make sure that the document is an original and that no 
tampering has taken place. If a digital certificate has been asserted with respect to the document, the 
appropriate certificate authority is contacted to determine 1304 whether the asserted certificate has been 
revoked. If the digital signature is reliant upon on a certificate, this step ensures that the certificate is valid 
and trustworthy. 

The data entered by the party is checked 1305 for completeness and accuracy; such a check may include 
verification of a correct syntax or number combination for various fields and the like. 

If, in steps 1303,1304, or 1305 any problems are found with the signature, certificate, or completeness of 
data, processing may stop and the user may be alerted as to the status of the document. Otherwise, 
processing continues with step 1306. 

Data is extracted 1306 from the completed form and provided to a back-end database (not shown). In one 
embodiment, the data is transmitted via Open Database Connectivity (ODBC) calls as are known in the 
art. The back-end database stores the extracted data for later retrieval when the document is to be 
reviewed or otherwise output. 
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Credit card, ACH, or otherElectronic Funds Transfer (ECF) is issued 1307 in accordance with user- 
supplied account information, as collected in various fields as described above. 

. In some circumstances, human review of the document may be. desirable before processing continues. If 
appjica^leithe document, is displayed 1308 for hum ..v-^...** ■> '• : . - : .- : -V ;•' — *>. ■ : '4 

Iri the example shown, a new identification number is generated 1309 for the applicant represented by the 
party signing the document. One skilled in the art will recognize that such a step is merely exemplary, and 
that any type of identification or other generated data element may be provided, as appropriate to the 
particular application. 

A back-end server (not shown) then records 1310 that the document has been accepted and signed, and 
the document is stored 131 1 in a database or other persistent storage. As described above, E-Cabinet 
352 permits selective access to the entire document or parts thereof, in accordance with various 
permissions and other parameters associated with the document and/or the person seeking access. Thus, 
when requested by a user and in accordance with permissions, authentication requirements, and security 
levels, the document is retrieved from the database and displayed 1312, for example on a browser under 
the user's control. Referring now to 

Figure 14, there is shown a system block diagram of one embodiment of a document management flow 
process in a signing room implemented according to the present invention. One skilled in the art will 
recognize that the process shown in Figure 14 is merely exemplary of a particular application of the 
present invention in one embodiment. 

A client, who may be one of the parties to a transaction, and who may be accessing the system of the 
present invention from a remote location, originates 1404 the signing room documents, either by 
generating the documents in a word processor or similar software application, or by uploading and 
converting existing documents. The process of creating and/or converting such documents is known in the 
art. 

Virtual File Clerk 1405, which is a business logic tier 343 functional module which forms an interface 
between presentation 342 and persistent storage 344 (including database 1409), processes the originated 
or converted documents and manages the document flow. 

As described above, presentation tier352, implements signing room 300, E 

Cabinet 352, and the like, for hosting and presenting documents, signing rooms, and the like. 

Presentation tier 352 may contain any number of virtual signing rooms 300. 

In the example of Figure 14, three such signing rooms 300 are shown for illustrative purposes: a 
Proposition 209 room 300A for implementing a transaction involving government legislation; an Investment 
Banking Transaction room 300B for implementing an investment transaction; and a Real Estate room 
300C for implementing a real estate transaction. One skilled in the art will recognize that many other types 
of virtual signing rooms 300 can be provided according to the present invention. 

Each signing room 300 contains information describing roles 1401, content 1402, and 
transactions/documents 1403. For example, the Proposition 209 room 300A contains four roles1401A 
(originator, moderator, participant, and observer), five content items 1402 A (documents of commerce, 
reports, white papers, discussion threads, and multi-dimensional links), and four sets of 
transactions/documents 1403A (petition, supporting/opposing documents, discussions, documents to 
sign). 

The Investment Banking Transaction room 300B contains four roles 1401 B (originator, moderator, 
participant, and observer), six content items 1402B (documents of commerce, reports, white papers, 
discussion threads, multi-dimensional links, and high security items), and six sets of 
transactions/documents 1403B (offer, supporting documents, letter of intent, evolving contract, digital 
signatures, and archive). The 

Real Estate room 300C contains four roles 1401C (originator, moderator, participant, and observer), five 
content items 1402C (documents of commerce, reports, white pa pers, discussion threads, and multi- 
dimensional links), and six sets of transactions/documents 1403C (listing, sale contract, loan applications, 
appraisals, loan documents, and deeds). 

In one embodiment, an archive 1410 is provided for long-term storage of any or all elements of signing 
rooms 300. The archive 1410 may include, for example, a chronology of events, revision logs, drafts, and 
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the like. The archive 1410 may be stored, for example, on a compact disc read-only memory (CD-ROM) 
device or the like, for convenient access at a later time. 

Referring now to Figure 15, there is shown a system block diagram of one embodiment of a document 
management flow process in a disclosure room implemented according to the present invention. One 
. . skilled :jn .the>art will recognize that .the process shown in Figure 15 is merely exemplary, of a particular 
application of the present Invention in dne embodiment. 

In several respects, the disclosure room process of Figure 15 is similar to the signing room process 
previously described in connection with Figure 14, although ingeneral, in a disclosure room, no application 
of digital signatures takes place. The client originates 1404 the disclosure room documents, either by 
generating the documents in a word processor or similar software application, or by uploading and 
converting existing documents. As before, the process of creating and/or converting such documents is 
known in the art. Virtual File Clerk 1405 processes the originated or converted documents and manages 
the document flow. Presentation tier 342 implements signing room 300, E-Cabinet 352, and the like, for 
hosting and presenting documents, interfacing with database 1502. In addition, traffic relating to the 
disclosure room can be archived 1507, if desired. 

Presentation tier 342 may contain any number of virtual disclosure rooms 1503. In the example of Figure 
15, one such signing room 1503 is shown for illustrative purposes: a Technology Preview room 1503. One 
skilled in the art will recognize that many other types of virtual disclosure rooms 1503 can be provided 
according to the present invention. 

Each disclosure room 1503 contains information describing roles 1504, content 1505, and 
transactions/documents 1506. For example, the Technology Preview room 1503 contains four roles 1504 
(originator, moderator, participant, and observer), six content items 1505 (documents of commerce, 
reports, white papers, discussion threads, multi-dimensional links, and high security items), and five sets 
of transactions/documents 1506 (confidential specifications, documentation, disclosure agreement, digital 
signatures, and archives). 

As with the example of Figure 14, in one embodiment, an archive 1410 is provided for long-term storage of 
any or ail elements of signing room 1503. The archive 1410 may include, for example, a chronology of 
events, revision logs, drafts, and the like. The archive 1410 may be stored, for example, on a compact disc 
read-only memory (CD-ROM) device or the like, for convenient access at a later time. 

Referring now to Figure 16A, there is shown a flowchart showing a signing room logon and entry method 
according to one embodiment of the present invention. In one embodiment, the steps of Figure 16A are 
performed by presentation tier 342 as described above in the context of the overall architecture. A user 
logs on 2301 to the signing room to obtain access to documents and other materials. As described above, 
the user access the system of the present invention over a network such as the 
Internet, using, for example, a browser. The user is presented with a contract describing terms of use of 
the virtual signing room, which he or she reads 2302. If the user deems the terms to be satisfactory, he or 
she indicates agreement 2303 to the terms, for example by clicking on an onscreen button. 

Once the user has indicated agreement, he or she arranges for payment 2304 for the virtual signing room 
sen/ice, such as for example by supplying a credit card number or enabling electronic funds transfer. The 
system of the present invention collects payment in accordance with the user's specifications, using 
techniques that are known in the art. 

The user then selects 2305 a security level for the virtual signing room. In one embodiment, the user can 
select from five security levels, though one skilled in the art will recognize that any number of security 
levels may be provided. In one embodiment, each of the security levels is associated with a different level 
and/or type of party authentication, including for example verification by passphrase, biometric data, 
smartcard, IP address, processor ID code, and the like. 

The user then selects 2306 a signing room to enter. This step may entail various substeps as described in 
more detail in connection with Figure 16B. The user is then given anopportunity to calendar 2307 
discussion, editing, and signing events within the context of the virtual signing room. Thus, various 
transaction-related events and items can be scheduled, depending on the nature and structure of the 
particular deal. In one embodiment, the calendared events are stored so that an overall schedule of the 
events can be retrieved, modified, or otherwise accessed when needed. 

The user enters 2308 a signing room, for example by selecting from a displayed list of available rooms to 
which the user has access. The user may select one of the displayed rooms, for example by clicking on an 
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onscreen button or link. The user then verifies his or her identity, providing the appropriate input in 
accordance with the signingroom's security level, and further verifies the role to which the user has been 
assigned. The present invention then allows the user to actively participate in the signing room activities, 
including viewing, modification, and signing of documents as his or her access level permits. 

: : !f desired; apd.-if/the access teveFpemlts such an opi^atiohv the -uyerimay ^^^reate 2309;a n.eyy document * v : \&J. 
Within the virtual signing room. In one Embodiment the user creates a new document by selecting from a 
number of available document templates, filling in additional information as appropriate for the selected 
template, attaching a digital signature(if applicable), and submitting the document to the virtual signing 
room. The document may then be made available to other users in the room, if appropriate. 

Referring to Figure 16B, there is shown a flowchart depicting a signing room admittance procedure 
according to one embodiment of the present invention. In one embodiment, the steps of Figure 16B are 
performed by presentation tier 342 as described above in the context of the overall architecture. The 
method of Figure 16B may be performed, for example, in the context of selecting a signing room as in step 
2306 of Figure 16A. 

When a user selects a signing room for access, the present invention verifies 2401 the permissions 
associated with the signing room, to ensure that the user is in fact permitted to access the specified room. 
The user selects 2402 a role, as described above, for his or her interaction with the documents and other 
parties in the signing room. Other participants in the room are then notified 2403 of the presence of the 
user, either by display of a dialog box, or an icon or other indicator, or by some other means. If 
appropriate, the user is also added 2404 to any discussion groups that may be taking place in the context 
of the room. 

The user is also given an opportunity to check in documents that he or she may have been creating and/or 
modified in an off-line environment. The user sets up 2405 permissions for the documents being checked 
in, and defines 2406 any required processes associated with the documents (such as a signing sequence 
or other transaction-related steps). The user also identifies 2407 the location or DOI of the documents 
being checked in. A test may be performed 2408 of the virtual form of the document (in other words, the 
representation of the document within the context of the virtual signing room). 

In addition, the user may define 2409 the outputs for the signing room, including for example whether 
templates, document creation or editing, and/or transactional signatures are to be provided in the context 
of the signing room. 

Referring now to Figure 16C, there is shown a flowchart depicting an account termination method 
according to one embodiment of the present invention. The method of Figure 16C may be performed, for 
example, when a user wishes to terminate a signing room, such as when a transaction is completed or 
aborted. Upon re ceipt of a user's request to terminate a signing room, the user's identity is verified 2501 , 
as are the user's rights in connection with account termination. If the identity rights are verified 
appropriately, the signing room is archived 2502 (such as to a CD 
ROM), and the signing room is deleted 2503. 

In one embodiment, participants in the room are warned of the impending deletion of the room. In 
alternative embodiments, the assent of other participants is sought prior to deletion. Each party may then 
request a copy of the archive (CD 
ROM), if desired and appropriate. 

Referring now to Figure 17, there is shown a flowchart depicting an example of an electronic signature 
collection method according to one embodiment of the present invention. The method of Figure 17 
illustrates a particular application of the present invention to the electronic collection of signatures for a 
petition. As such, the various elements and specific components of Figure 17 are merely exemplary. 

The invention presents a welcome screen 1701, as may be provided using a web page viewable in a 
browser application. The welcome screen 1701 includes a link or button allowing the user to access a 
selected initiative for viewing and/or signing. Once the user has selected an initiative, he or she selects 
1702 a county from a displayed list. In some cases, the displayed petition will vary depending on the 
selected county. 

The user is then presented with an entry screen 1703 for the virtual signing room. The user is asked to 
select one of four roles, depending on the activity he or she would like to perform with respect to the 
signing room. In the example of Fig ure 17, the four available roles are petition viewer, petition signer, 
circulator (whose function is to witness signatures and answer questions), and administrator. 
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If in screen 1703 the user selects the petition viewer role, the invention displays a view petition screen 
1704 from which the user can select various items for viewing. In the context of a petition, examples 
include a proponent's statement, an opponent's statement, press releases, and the like. In addition, a chat 
room facilitating real-time communication may be provided and accessible from screen 1704, using 
\ /techniques that are known in:the-art»>. : ..... . v. .. - ,, 

If in screen 1703 the user selects the petition signer role, the invention determines 1705 whether the user 
has previously set up a digital signature, as described above. If so, the signature is verified 1706, and the 
user is given anopportunity to sign 1708 the petition. In the context of a petition signing application, certain 
items of information may be presented and/or collected in the course of the signing operation of step 1708, 
as shown in Figure 17. In one embodiment, drop-down lists may be provided in the sign petition screen 
1708, allowing the signerto"place"identify- ing information within the petition document itself in the course 
of signing it. 

If in step 1705 the invention determines that the user has not previously set up a digital signature, the user 
is prompted to enter identifying information (such as driver's license number, social security number, and 
the like) to initiate the process of configuring a new digital signature. Once the digital signature has been 
enabled, the invention proceeds with step 1708. 

After step 1708 has been completed, the invention determines 1709 whether the registration data supplied 
by the user is valid. If so, the petition is signed 1710. 

Registration is reported as complete, the user is prompted to click a button to apply the signature, a key 
pair is generated, the petition is signed with the private key, the private key is deleted, a public key is 
attached to the petition, and the petition is stored. If in step 1709 the registration data is not valid, the 
petition is not signed 171 1. Registration is reported as not complete, a chat is initiated with the circulator to 
resolve the registration problem, new registration data is obtained, and data is submitted for matching with 
a registered voter list. Step 1709 may then be reattempted with the new registration data. 

If in screen 1703 the user selects the circulator role, a logon/logoff screen 1712 is presented allowing the 
user to specify whether he or she wishes to log on or log off. If logon is selected, the user is presented 
with a logon screen 1713. If logoff is selected, he or she is presented with a logoff screen 1714. Once the 
circulator has logged on, he or she is able to perform relevant activities as are applicable, such as witness 
signatures and the like. 

If in screen 1 703 the user selects the administrator role, several administrator functions become available 

1715, such as: 

setting up a new initiative; 

creating a new circulator; 

* generating reports on signatures; 
generating totals; 

* generating county subtotals; 

* generating disk-based signature lists; 

generating holographic labels for circulator use (where states may re 
quire that the circulator prepare a label in his or her own handwriting); 
generating tools for county election officials to tabulate, verify, and/or 
withdraw signatures. 

As mentioned previously, the specific items listed above in connection with the example of Figure 17 are 
merely exemplary of one embodiment of the present invention. 

Referring now to Figures 18A-D, there are shown screen shots depicting an example of a signing room 
according to one embodiment of the present invention. 

Home page 1800 provides the user with options for selecting roles such as petition viewer, petition signer, 
circulator, and administrator, as described above in step 1703 of Figure 17. Signing room 1801 shows an 
example of a petition as displayed in accordance with the petition signer role. The title and a summary of 
the petition are displayed, and the user is given anopportunity to digitally sign the petition as described in 
( step 1 708 of Figure 1 7. In the example of Figure 18B, the user is prompted for a first name, middle name 

or initial, last name, address, city, ZIP code, and either a social security number or California driver's 
license number, in order to initialize the digital signature. 

Page 1802, which may be displayed in connection with step 1710 of Figure 17, confirms to the user that 
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he or she is registered and may sign the petition by clicking on the appropriate on-screen button 1804. 



Page 1803, which may be displayed in connection with step 171 1 of Figure 17, opens a chat session with 
the circulator in order to resolve registration issues. The user can then communicate with the circulator 
over the chat channel, in accordance with known techniques for on-line instant messaging or"chat". 

Referring nbw to Figure 19, thfcre is Shown a flowchart depicting a deed fecbrdihg method according to 
one embodiment of the present invention. The particular sequence of steps shown in Figure 19 may be 
performed, for example, by a computer or set of computers following a set of instructions specified in 
software code. 

The sample method of Figure 19 illustrates an application of the present invention to a simple deed 
recording transaction, though one skilled in the art will recognize that other types of transactions, including 
more complex transactions, could be enabled using the present invention. A user prepares 1901 the deed 
using a conventional browser interface with form fields and the like. Upon completion, the deed is 
automatically e-mailed 1902 to a recorder and received 1903 at a central server (not shown). The 
invention parses 1904 the received deed in order to extract information for storage in the database 1409; 
in addition, if the deed has been digitally signed, information describing or confirming the digital signature 
is stored. If in 1905 a filing fee is to be collected, the fee is collected 1906, for example by charging the 
user's credit card or by effecting an electronic funds transfer. 

If in 1907 the deed is not recordable, it is returned 1908 to the originator with an explanation of the 
rejection. If it is recordable, the invention verifies 1909 the document integrity 1909 and the digital 
signature 1910. If in 191 1 the document is not approved (e. g. due to problems with document integrity 
and/or signatures), it is returned 1912 to the originator with an explanation of the rejection. 

If the document is approved, the deed is recorded 1913 and a notice of recording is returned 1914. The 
deed, in digital form, is stored 1915 in database 1409 for future use and access. Database 1409 is 
updated 1916 to reflect the recorded deed. 

In addition, if desired, the deed is transmitted 1 91 7 to the assessor, printed 1 91 8 to paper, and/or printed 
1919 to microfiche. 

The above description is included to illustrate the operation of the preferred embodiments and is not 
meant to limit the scope of the invention. The scope of the invention is to be limited only by the following 
claims. From the above discussion, many variations will be apparent to one skilled in. the art that would yet 
be encompassed by the spirit and scope of the present invention. 

Appendix A 

The following is an example of an XML-encoded document 102 corresponding to the agreement document 
depicted in Figures 6A-6B. One skilled in the art will recognize that the document may be encoded by 
other means and in other languages adapted to numerous specific applications and contexts. 

<XML> 

- < BODY background="sandstrip~bkg~frame. gif > 

- < TR > 

- < TD > 

< IMGalt= ,,w src="iogo midsize. gifV > 
</TD> 

< TD align="right" > 
powered by 
<BR/> 

< IMG alt=""src="Hi Res LogoStrans. gif 
sty le="H EIGHT: 31 px; WIDTH: 137px7 > 
<BR/> 

Patents Pending 

<BR/> 

</TD> 

</TR> 

< /TABLE > 

- < FONT face=Tahoma n > 

< STRONG > U. S. Distributor Application & Agreement < /STRONG > 

< /FONT > 
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<P/> 

- < TBS id="Morinda" > 

< TBS id="Applicant" > 
-< TABLE > 

-<TR> .. ; • ; ■ . t . r . -: ... . . ........ ... . .. v . 

• < TD align = w right"> . -m-w,/: . ;,-V : • -^fAv \- Y.- ■'■ ^ 

< STRONG > Persoriallnformation < /STRONG > : ' " : <'" ' v 

< /TD > 
-<TD> 
< 

< FONT color="red" > * < /FONT > 
Required Information) < /TD > 
</TR> 

-<TR> 

< TD align="right M > Applicant'sName < /TD > 

- < TD > - < AppName > 

< INPUT value="*Last, First, Middle" size="30"style="BACKGROUND-COLOR: 
bisque"/ > 

< /AppName > 
</TD> 
</TR> 
-<TR> 

< TD align-Yight" > Applicant's SS Number < /TD > 
-<TD> 

- < AppSSN > 

< INPUT 

< /AppSSN > 

< INPUTtype="button"value-"Note" 
style="BACKGROUND-COLOR: tan"on 
Click="alert (The Social Security Number 
is absolutely required. 1 )"/ > 

< /TD > 

< /TR > - < TR > 

< TD align-Yight" > Spouse (or Co-Applicant's 
Name) < /TD > 

- < TD > 

- < CoAppName > 

< INPUTsize="30"style="BACKGROUND- 
COLOR:bisque"value="Last, First, 
Middle"/ > 

< /CoAppName > 

< INPUTtype="button"val~e="Note" 
style="BACKGROUND-COLOR: tan"on 
Click-'alertCHaving a co-applicant is op 
tional. It is highly recommended that the 
spouse information be filled out as the 
spouse is considered as having a benefi 
cial interest in thedistributorship.')" 

/> 

</TD> 

< /TR > - < TR > 

< TDalign-Yight" > Spouse (or Co-Applicant's) 
SSN < /TD > 

-<TD> 

< CoAppSSN > 

< INPUTsize="1 1 "styie="SACKGROUND- 
COLOR: bisque"value="nnn-nn-nnnn7 > 

< /CoAppSSN > 
<fTD> 

< /TR > - < TR > 

< TD align-Yight" > U. S. Mailing Address < /TD > 

- < TD > - < AppAdd > 

< lNPUTsize="30"value="*" 
style="BACKGROUND-COLOR: bisque"/ > 
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< /AppAdd > 

< INPUTtype="button"value="Note" 
style="BACKGROUND-COLOR: tan"on 
Click="alertCWe must have a second ad 
dress for shipping if your mailing address . 

■"• :-':is;'a'PP-BpxV.6iv'if youWouid like your >. ■{ ... - . -. .■ r --v V-'-- V' •■• -'■ '.T : 

AutdShip sent tban : alternate address.')" 
/> ■ 
<fTD> 

< fTR > - < TR > 

< TD align="right" > City, State, Zip Code < /TD > 
-<TD> 

< AppCity > 

< INPUTsize="10'Value="*" 
style-'BACKGROUND-COLOR: bisque"/ > 

< /AppCity > 

- < AppST > 

- < SELECT size=Tstyle="BACKGROUND- 
COLOR:bisque" > J 

< OPTION > AL < /OPTION > < OPTION > AK < /OPTIOH > 

< OPTION > AZ < /OPTION > < OPTION > AR < /OPTION > 

< OPTION SELECTED-"' > CA < /OPTION > 

< OPTION > CO < /OPTION > 

< OPTION > CN < /OPTION > 

< OPTION > DE < /OPTION > 

< OPTION > FL < /OPTION > 

< OPTION > GA < /OPTION > 

< OPTION > HA < /OPTION > 

< OPTION > ID < /OPTION > < OPTION > IL < /OPTION > 

< OPTION > IN < /OPTION > 

< OPTION > IO < /OPTION > 

< OPTION > KA < /OPTION > 

< OPTION > KY < /OPTION > 

< OPTION > LO < /OPTION > 

< OPTION > ME < /OPTION > 

< OPTION > MD < /OPTION > 

< OPTION > MA < /OPTION > < OPTION > Ml< /OPTION > 

< OPTION > MN < /OPTION > 

< OPTION > MO < /OPTION > 

< OPTION > MT < /OPTION > 

< OPTION > NE < /OPTION > < OPTION > NV < /OPTION > 

< OPTION > NH < /OPTION > 

< OPTION > NJ < /OPTION > < OPTION > NM < /OPTION > 

< OPTION > NY < /OPTION > < OPTION > NC < /OPTION > 

< OPTION > ND < /OPTION > 

< OPTION > OH < /OPTION > 

< OPTION > OK < /OPTION > 

< OPTION > OR < /OPTION > 

< OPTION > PN < /OPTION > 

< OPTION > Rl< /OPTION > 

< OPTION > SC < /OPTION > 

< OPTION > SD < /OPTION > 

< OPTION > TN < /OPTION > < OPTION > TX < /OPTION > 

< OPTION > UT < /OPTION > 

< OPTION > VT < /OPTION > 

< OPTION > Vl< /OPTION > < OPTION > WA < /OPTION > 

< OPTION > WV < /OPTION > 

< OPTION > Wl< /OPTION > 

< OPTION > WY < /OPTION > 

< /SELECT > 

< /AppST > 

< AppZip > 

< INPUTstyle="BACKGROUND-COLOR: bisque" size="8"value="*nnnnn-nnnn7 > 

< /AppZip > 
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< /TR > - < TR > 

< TDalign="right" > Date of Birth < /TD > 
-<TD> . 

.. < AppDOB > - < SELECT size=Tstyle="BACKGROUND-: 
-COLOR:. bisque";> : --' -V -V 

< OPTION seiected="" > Jan < /OPTION > 

< OPTION > Feb < /OPTION > 

< OPTION > Mar < /OPTION > 

< OPTION > Apr < /OPTION > < OPTION > May < /OPTION > 

< OPTION > Jun < /OPTION > 

< OPTION > Jul < /OPTION > 

< OPTION > Aug < /OPTION > 

< OPTION > Sep < /OPTION > 

< OPTION > Oct < /OPTION > 

< OPTION > Nov < /OPTION > 

< OPTION > Dec < /OPTION > 

< /SELECT > < SELECT size=Tstyle="BACKGROUND 
COLOR: bisque" > 

< OPTIONselected= n " > 01 < /OPTION > 

< OPTION > 02 < /OPTION > 

< OPTION > 03 < /OPTION > < OPTION > 04 < /OPTION > 

< OPTION > 05 < /OPTION > 

< OPTION > 06 < /OPTION > 

< OPTION > 07 < /OPTION > < OPTION > 08 < /OPTION > 

< OPTION > 09 < /OPTION > 

< OPTION > 10 < /OPTION > 

< OPTION > 1 1 < /OPTION > 

< OPTION > 12 < /OPTION > 

< OPTION > 13 < /OPTION > 

< OPTION > 14 < /OPTION > 

< OPTION > 15 < /OPTION > 

< OPTION > 16 < /OPTION > 

< OPTION > 17 < /OPTION > 

< OPTION > 18 < /OPTION > < OPTION > 19 < /OPTION > 

< OPTION > 20 < /OPTION > 

< OPTION > 21 < /OPTION > 

< OPTION > 22 < /OPTION > 

< OPTION > 23 < /OPTION > 

< OPTION > 24 < /OPTION > 

< OPTION > 25 < /OPTION > 

< OPTION > 26 < /OPTION > 

< OPTION > 27 < /OPTION > 

< OPTION > 28 < /OPTION > 

< OPTION > 29 < /OPTION > < OPTION > 30 < /OPTION > 

< OPTION > 31 < /OPTION > 

< /SELECT > 

, 19 < SELECT size=Tstyle="BACKGROUND- 
COLOR: bisque" > 

< OPTIONselected-"' > 0 < /OPTION > < option > I < /option > 

< option > 2 < /option > 

< option > 3 < /option > 

< option > 4 < /option > 

< option > 5 < /option > 

< option > 6 < /option > 

< option > 7 < /option > 

< option > 8 < /option > 

< option > 9 < /option > 

< /SELECT > < SELECT size="1"style="BACKGROUND- 
COLOR: bisque" > 

< optionselected="" > 0 < /option > < option > I < /option > 

< option > 2 < /option > 

< option > 3 < /option > 

< option > 4 < /option > 
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< option > 5 < /option > 

< option > 6 < /option > < option > 7 < /option > 

< option > 8 < /option > 

< option > 9 < /option > 
< /SELECT > 

: < INPUT type="buttbn"vaiUe- n Note" 
ssy le= M B ACKG ROUN D-COLOR: tan"on 

</TD> 

< /TR > - < TR > 

< TD align= n right" > Daytime Phone < /TD > 

- < TD > - < AppDPh > 

< lNPUTsize="1 0 n style="BACKGROUND- 
COLORibisque'Value-^nnn-nnn-nnnn" 
/> 

< /AppDPh > 

< INPUTtype= M button"value="Note" 
style-'BACKGROUND-COLOR: tan"on 
Click="alert ('Please indicate the numbers 
where you may be reached .*)7 > 

< /TD > 
</TR> 

< TD align= M right" > Alternate Phone < /TD > 

- < TD > - < AppOPh > 

< INPUTsize= n 10"style="BACKGROUND- 
COLOR:bisque"value="*nnn-nnn-nnnn" 
/> 

< /AppOPh > 
</TD> 

< /TR > - < TR > 

< TDalign="right" > Evening Phone < /TD > 

- < TD > - < AppEPh > 

< INPUTsize="10 M style="BACKGROUND- 
COLOR:bisque"value="*nnn-nnn-nnnn" 
/> 

< /AppEPh > 
</TD> 

< /TR > - < TR > 

< TD align="right" > Cellular Phone < /TD > 

- < TD > Z < AppCPh > 
<INPUTsize="10 w style="BACKGROUND 
COLOR:bisque"value="nnn-nnn-nnnn7 > 

< /AppCPh > 
<fTD > 

< /TR > - < TR > 

< TD align= n right n > FAX < /TD > 

- < TD > - < AppFAX > 

< INPUTsize="10"style="BACKGROUND- 
COLOR: bisque"value="nnn-nnn-nnnn7 > 

< /AppFAX > 
</TD> 

< /TR >< TR > 

< TD align= M right" > E-Mail Address < /TD > 

- < TD > - < AppEM > 

< INPUTstyle="BACKGROUND-COLOR: bisque" 
size= M 307 > 

< /AppEM > 
</TD> 

< /TR > - < TR > 

< TD align= w right7 > 
-<TD> 

< INPUTtype- 'button^alue^Generate Keys" 
onclick= w navigate( , morindagenerate. htm')" 
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style= n BACKGROUND-COLOR: tan7 > 

< INPUTtype="button"value="Explain"on- 
click="navigate ('http://www. whatis. com/pki 
.htm'y'style-'BACKGROUND-COLOR: tan"/ > 

<fTD> : , ; 

'j^i^fTR >V:<TR >-''. '; ' • 'o'**' ' r---V- -** : -.-.v.' " - ■ vv- . -V" '. : :V- ~* **•• ■'. ' ••■:' ! ».-*.r v--* - V" 

? <TDalign^ ' " v " . T 5 ' : 'V'. : : ' "• ' - ; '/ " ' " 

<TD/> 

< fTR > - < TR > 

< TD align="right n > 

< STRONG > *Personal Sponsor's Informa 
tion < /STRONG > 

< /TD > - < TD > 

The distributor that referred you to the 
company. 



*<BR/> 

Placement and personal sponsors may be the 
same. 

< INPUTstyle="BACKGROUND-COLOR: tan"on 
click^alertfYour placement and personal 
sponsor may be the same distributor if you 

are on the personal sponsors first level 

and have not been placed.')"type="button" value="Note7 > 

</TD> 

< fTR > - < TR > 

< TDalign="right" > Name < /TD > 

- < TD > - < PSIName > 

< INPUTsize="30"style="BACKGROUND- 
COLOR:bisque"value="*Last, First, 
Middle"/ > 

< /PSIName > 
</TD> 

< /TR > - < TR > 

< TD align="right" > Phone < /TD > 

- < TD > - < PSIPh > 

<JNPUTsize="10"styIe="BACKGROUND 
COLOR:bisque"value="nnn-nnn-nnnn7 > < /PSIPh > 
</TD > 

< /TR > - < TR > 

< TD align="right" > ID Number < /TD > 

- < TD > - < PSINum > 

<INPUTsize="8"style="BACKGROUND-COLOR: 
bisque"value="nnnnnnnn7 > 

< /PSINum > 
</TD> 

< /TR > - < TR > 
<TDalign="right"/> 
<TD/> 

< fTR > - < TR > 

< TD align="right" > 

< STRONG > Placement Information < /STRONG > 

< /TD > - < TD > 

It is highly recommended that you - < STRONG > 

< EM > NOT < /EM > 

< /STRONG > 

fill out placement information upon sign-up. 

< INPUT onclick="alert (The Placement Sponsor 
is the distributor that you are placed di 

rectly under. Placement sponsor must be in 
thedownline of your Personal sponsor. It 
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is highly recommended that you NOT fill 
out placement information upon sign-up. 

Leaving it blank will give your personal 
. sponsor .1.20 days Jo determine where to 
. : pfaceybu using'a placement s^n^ y<'» •.- •<*: .i / :: V -v v'-v:: "'• m '' v -K''.^'k !.r : v "l 

form: This is your one placement. If you • . ... 

are placed anywhere other than your Per 

sonal Sponsors first level, you cannot be moved. ') M style="BACKGROUND-COLOR 
"style="BACKGROUND-COLOR tan" 
type= H button M value="Note7 > 
</TD> 

< UR > - < TR > 

< TD align="right" > Name < /TD > 

- < TD > - < PIName > 

< INPUTsize="30"style="BACRGROUND- 
COLOR:bisque"value="Last, First, 
Middle"/ > 

< /PIName > 
</TD> 

< /TR > - < TR > 

< TD align="right" > Phone < /TD > 

- < TD > - < PIPh > 

<INPUTsize="10"style="BACKGROUND- 
COLOR: bisque"value="nnn-nnn-nnnn7 > 

< /PIPh > 
</TD> 

< UR > - < TR > 

< TDalign="right M > ID Number < /TD > 

- < TD > - < PINum > 

< lNPUTsize="8"style="BACKGROUND-COLOR: 
bisque"value="nnnnnnnn7 > 

< /PINum > 
</TD> 

< /TR > - < TR > 

< TDalign="right7 > 

< TD/ >< /TR > - < TR > 

- < TDalign="right" > 

< STRONG > Case AutoShip Program < /STRONG > 

< /TD > - < TD > 

< INPUTtype="button"valv=="EnroH M on- 
click="navigateCmorindaauto. htm 1 )" 
style= M BACKGROUND-COLOR: tan"/ > 
me in Morinda's Case AutoShip Program. 

</TD> 

< /TR > - < TR > 

< TD align="right7 > 
<TD/> 

< /TR > - < TR > 

- < TD align-Yight" > 

< STRONG > Nonresident Alien Distribu 
tors < /STRONG > 
</TD > 
-<TD> 

- < AppAlien > 

< INPUTtype="checkbox" 
style="BACKGROUND-COLOR: bisque"/ > 

< /AppAlien > 

I am living in the United States, but am not 
a U. S. Citizen. Nonresident Aliens in the 
U. S. are required by law to submit an IRS 
Form W-8 
</TD > 
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< /TR > - < TR > 

< TD align="right"7 > 
<TD/> 

< /TR > - < TR > 

< TD align="right" > ... 

»'. - : VSTRON6^.^hUijpW'<^TRONG',i>. : V.--' Vr 1 ^ y -' : -\\-':^- :'}■/■■ - : . f .-^ v ' : ..■ ?••«.*•■. .<? 

<ttd > ••' *•*;" • ; • ; ■ 

< TD > non-refundable$20.00 < /TD > 

< /TR > - < TR > 

< TDalign="right" > Method of payment < /TD > 
-<TD> 

- < AppPay > 

< SELECT size="1"style="BACKGROUND- 
COLOR: bisque" > 

< OPTION selected="" > VISA < /OPTION > 

< OPTION > M/C < /OPTION > < OPTION > DISCOVER < /OPTION > 

< /SELECT > 

< /AppPay > 
OR 

<INPUTtype="button"value="ACH"on 
click-'navigate ('morindaACH. htm')" 
style="BACKGROUND-COLOR: tan"/ > 
</TD> 

< /TR > - < TR > 

< TD align="right" > Credit Card# < /TD > 

- < TD > - < AppCCN > 

< INPUTstyle="BACKGROUND-COLOR: bisque" 
/> 

< /AppCCN > 
Exp Date 

< AppED > 

- < SELECTsize=Tstyle="BACKGROUND- 
COLOR: bisque" > 

< OPTIONselected="" > Jan < /OPTION > < OPTION > Feb < /OPTION > 

< OPTION > Mar < /OPTION > 

< OPTION > Apr < /OPTION > < OPTION > May < /OPTION > 

< OPTION > Jun < /OPTION > < OPTION > Jul < /OPTION > 

< OPTION > Aug < /OPTION > 

< OPTION > Sep < /OPTION > 

< OPTION > Oct < /OPTION > < OPTION > Nov < /OPTION > 

< OPTION > Dec < /OPTION > 

< /SELECT > < SELECT size="1"style="BACKGROUND- 
COLOR: bisque" > 

< OPTIONselected="" > 1999 < /OPTION > 

< OPTION > 2000 < /OPTION > 

< OPTION > 200 1 < /OPTION > 

< OPTION > 2002 < /OPTION > 

< OPTION > 2003 < /OPTION > 

< OPTION > 2004 < /OPTION > 

< /SELECT > 

< /AppED > 
</TD> 
</TR> 
-<TR> 

< TDalign="right7 > 

< TD/ > 
</TR> 
-<TR> 

< TD align="right"valign="top" > 

< STRONG > Signature < /STRONG > 
</TD> 

< TD > The undersigned hereby applies to become an 
independent distributor of Morinda, Inc. As an 
independent distributor, I agree to the Terms 
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and Conditions and in the Morinda Distributor 
Manual. < /TD > 

< /TR > 

- < TR > 

- '< TD colspan="2 n align="middle" > . 

• . ; < TEXTAR^TfeadOrily=^Style=' ! BAGKG ROUND-- . : v. : ...... ;.;,v.u... , :.j-y. ...y:\::; r ^.-\ 

COLOR: bisque; HEIGHT: 122px; WIDTH: 
500px" > TERMS ANDAGREEMENT: Distributor 
and Morinda Inc. (Morinda) hereby agree to 
the following terms and conditions: 

< /TEXTAREA > 

<fTD> 
</TR> 
-<TR> 

< TD align="right7 > 
-<TD> 

< INPUT type="button"value="Sign Document" 
style="BACKGROUND-COLOR: tan"on 
click="navigate('morindasignl. htm')7 > 
</TD> 

</TR> 

< /TABLE > < /TBS > 

< SIGN id=" Applicant"/ > < /TBS > < SIGN id="Morinda7 > 

< CERTid=" Applicant"/ > < CERTid="Morinda7 > 

< /BODY > < /XML > 
Appendix B 

The following is an example of an XML-encoded document 102 corresponding to the agreement document 
depicted in Figures 6A-6B, after it has been completed and digitally signed. One skilled in the art will 
recognize that the document may be encoded by other means and in other languages adapted to 
numerous specific applications and contexts. 

<XML> 

< BODY background="sandstripbkgframe. gif > 

- < TABLE width="500" > 
-<TR> 

-<TD> 

< IMGalt=""src="logo-midsize. gif / > 
<fTD> 

< TD align="right" > 
powered by 
<BR/> 

< IMGalt=""src="Hi Res Logo5trans. gif 
style="HEIGHT:31px; WIDTH: 137px7 > 
<BR/> 

Patents Pending 
<BR/> 
</TD> 
</TR> 

< IT ABLE > 

- < FONT face="Tahoma" > 

< STRONG > U. S. Distributor Application & Agreement < /STRONG > 

< /FONT >< PI > 

- < TBS id="Morinda" > 

< TBS id="Applicant" > 

- < TABLE > 

- < TR > 

- < TD align="right" > 

< STRONG > Personallnformation < /STRONG > 
</TD> 

-<TD> 
( 

< FONT color="red" > * < /FONT > 
Required Information) 

</TD > 
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< /TR > - < TR > 

< TD align= n right" > Applicant's Name < fTD > 
-<TD> 

< AppName > BROWN, BRUCE < /AppName >< fTD > 
</TR>-<TR> 

" • -<Tb> ' ■' • ' ■ - ■■■ 

< AppSSN > 529-66-2094 < /AppSS :: > 
</TD> 

<H"R> 

< TD align= n right n > Spouse (or Co-Applicant's 
Name) < /TD > 

<TD> 

< CoAppName > BROWN, PATTI < /--ppName > 
</TD > 

< /TR > - < TR > 

< TD align- 'right" > Spouse (or Co-Applicant's) 
SSN</TD> 

- < TD >< CoAppSSN > 528-76-2759 < /CoAp ? SSN > 
</TD> 

< /TR >< TR > 

< TD align="right" > U. S. Mailing Address <fJD> 

- < TD > 

< AppAdd > 1684 North Sage Hen Road < /AppAdd > 
<fTD> 

< /TR >< TR > 

< TD align="right" > City, State, Zip Code < /TD > 
-<TD> 

< AppCity > OREM < /AppCity > 

< AppST > UT < /AppST > 

< AppZip > 84097-231 7 < /AppZip > 
</TD> 

< /TR > - < TR > 

< TD align="right" > Date of Birth < /TD > 

- < TD >< AppDOB > FEB01,1952 < /AppDOB > 
</TD> 

</TR> 

< TD align-'right" > Daytime Phone < /TD > 

- < TD >< AppDPh > 801 -852-8800 < /AppDPh > 
</TD> 

< /TR >< TR > 

< TD align="right" > Alternate Phone <UD> 
-<TD> 

< AppOPh/ > 
</TD> 

< /TR > - < TR > 

< TD align="right" > Evening Phone < /TD > 
-<TD> 

< AppEPh > 801-225-0983 < /AppEPh > 
</TD> 

< /TR > - < TR > 

< TD align="right" > Cellular Phone < /TD > 
-<TD> 

< AppCPh > 801-376-0983 < /AppCPh > 
</TD> 

< /TR > - < TR > 

< TD align="right" > FAX < /TD > 

- < TD >< AppFAX > 801 -852-881 0 < /AppFAX > 

< fTD >< /TR > - < TR > 

< TD align="right" > E-Mail Address < fTD > 

- < TD >< AppEM > bruce@ilumin.com < /A--EM > 
</TD> 

< /TR > - < TR > 

< TD align="right7 > 



http://v3 .espacenet.com/textdes?DB=EPODOC&IDX=EP 1 1 775 1 7&QPN=EP1 1 775 1 7 



esp@cenet description view Page 29 of 3 1 

<TD/> 
</TR> 

- < TD align="right" > 

< STRONG > 'Personal Sponsors Informa 
tion < /STRONG > ; . 

. •:y-<fFD ^'<ti> .v.-l ^v' r \ : .; ■•.:/.^^ C : v-.' • >...* 5" v-.-. '^s.^ v -li," 

"•''■"the distributor that referred you to the % "■ ' * 

company. 

< BR/ > 

Placement and personal sponsors may be the 
same. 

< INPUTstyle="BACKGROUND-COLOR: tan"on 
click- ? alert ('Your placement and personal 
sponsor may be the same distributor if you 

are on the personal sponsors first level 
and have not been placed.')"type="button" 
value="Note7 > 
</TD > 

< /TR > - < TR > 

< TD align="right" > Name < /TD > 

- < TD > 

< PSIName > ISRAELSEN, D. BRENT < /PSIName > 
</TD> 

< /TR > - < TR > 

< TDalign="right" > Phone < /TD > 
-<TD> 

< PSIPh > 801-376-6166 < /PSIPh > 
</TD> 

< /TR > - < TR > 

< TDalign^'right" > ID Number < /TD > 

- < TD > 

< PSINum > 11223344 </PSINum > 
</TD> 

< /TR > - < TR > 

< TDalign="right7 > 
<TD/> 

< fTR > - < TR > 

- < TD align="right" > 

< STRONG > Placementlnformation < /STRONG > 

< /TD > - < TD > 

It is highly recommended that you - < STRONG > 
<EM>NOT</EM> 

< /STRONG > 

fill out placement information upon sign-up. 

< INPUT onclick="alert (The Placement Sponsor 
is the distributor that you are placed di 

rectly under. Placement sponsor must be in 
thedownline of your Personal sponsor. It 
is highly recommended that you NOT fill 
out placement information upon sign-up. 

Leaving it blank will give your personal 
sponsor 1 20 days to determine where to 
place you using a placement sponsor change 
form. This is your one placement. If you 
are placed anywhere other than your Per 

sonal Sponsors first level, you cannot be moved. , ) , 'style="BACKGROUND-COLOR 
"style="BACKGROUND-COLOR tan" 
type="button"value= ,, Note7 > 
</TD> 

< fTR > - < TR > 
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< TDalign="right n > Name < /TD > - < TD > 

< PIName/ > 
</TD> 

< /TR > - < TR > 

", < TDalign -'right" > Phone < /TD > 

' < 7td £ v " • 

< /TR > - < TR > 

< TDalign="right n > ID Number < /TD > 
-<TD><PINum/> 

</TD> 

< /TR > - < TR > 

< TDalign="right7 > < TD/ > 

< /TR > - < TR > 

< TD align ="right7 > 
<TD/> 

< /TR > - < TR > 

< TD align ="right" > 

< STRONG > Nonresident Alien Distribu 
tors < /STRONG > 

< /TD > - < TD > 

< AppAlien > no < /AppAlien > 

I am living in the United States, but am not 
a U. S. Citizen. Nonresident Aliens in the 
U. S. are required by law to submit an IRS 
Form W-8 
</TD> 

< /TR > - < TR > 

< TDalign= M right7 > 
<TD/> 

< /TR > - < TR > 

- < TD align="right" > 

< STRONG > Sign-up fee < /STRONG > 
</TD> 

< TD > non-refundable$20.00 < /TD > 

< /TR > - < TR > 

< TDalign^right" > Method of payment < /TD > 
-<TD> 

< AppPay > VISA < /AppPay > 
</TD> 

</TR> 
-<TR> 

< TD align="right" > Credit Card# < /TD > 

- < TD >< AppCCN > 3752-xxxxx-xxxx < /AppCCN > 
Exp Date 

< AppED > Jan 2002 < /AppED > 
<fTD> 

</TR> 
-<TR> 

< TD align="right7 > 
<TD/> 

</TR> 
-<TR> 

< TD align^right'Valign-'top" > 

< STRONG > Signature < /STRONG > 
</TD> 

< TD > The undersigned hereby applies to become an 
independent distributor of Morinda, Inc. As an 
independent distributor, I agree to the Terms 

and Conditions and in the Morinda Distributor 

Manual. < /TD > 

<fTR> 

-<TR> 

- < TD colspan="2"align="middle w > 



Page 30 of 31 



http://v3.espacenet.com/textdes?DB=EPODOC&IDX=EP 1 1 775 1 7&QPN=EP 1 1 775 1 7 1/28/2004 



esp@cenet description view 



Page 31 of 31 



< TEXTAREAreadOnly=""style="BACKGROUND- 
COLOR: bisque ; HEIGHT: 122px; WIDTH: 
500px" > TERMS ANDAGREEMENT: Distributor 
and Morinda Inc. (Morinda) hereby agree to 

the following terms and conditions: 

?...:.'< /TEXTAREA > -\ ' : . -Vy " '" •■Vv\ : ^.^/^v'-^'-ivS/.V'-t • -^v 

</TD> ■' • . :;■ • 

</TR> 
- < TR > 

< TD align="right'V > 
<TD/> 

</TR> 

< /TABLE > 
</TBS> 

Digital Signature of Applicant 
<BR/> 

< SIGNid=" Applicant" > la 1 1 7c 4b c9 00 c3 dc 54 6e 3d c7lb c4 
6a 30 b7 54 5alc 71 48 c8 ec bef8 dd fd cefO 17 3d 17 05 

d7 cd fb 47 37 d3 9c de ff 3b 64 Ob la 4c 1 5 5b 7e cb a3 c4 

bb le 84 37 2b 20 60 9c 830c < /SIGN > 

<BR/> 

</TBS> 

< SIGN id="Morinda7 > 
Certificate of Applicant 
<BR/> 

< CERT id="Applicant" > e9 be 75 71 74 30f2 96 8f 73 47 ee 43 c9 71 
ec 27 98 6d 1 6 5b ec 55 e4 e5 81 9c c2 30 52 Iaf9 31 b3 55 06 

02 dc 1 5 dl 02 1 1 41 b6bc 5a 9f d8 54 97 3a 02 8d 7cca 2a 2c 
7c fl 9a 8c 79 fe 54 < /CERT > 

< CERT id="Morinda'7 > 

< /BODY > < /XML > 
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COLLABORATIVE CREATION, EDITING, REVIEWING, AND SIGNING OF 
ELECTRONIC DOCUMENTS 



Claims 

What is claimed is: 

1 . A computer-implemented virtual signing room for providing access to at least one document by a 
plurality of users from a plurality of remote locations, comprising: 

a document management module, for managing the at least one docu 
ment, the document management module comprising a docu 
ment-to-party mapping module for specifying access rights to 
the at least one document; and 

a deal management module, coupled to the document management 
module, for maintaining a deal completion list containing 
document-related task items. 

2. The virtual signing room of claim 1 , wherein the at least one document is encoded in an extensible 
markup language (XML) format. 

3. The virtual signing room of claim 1 , wherein the document management module further comprises an 
audit module for tracking revisions to the at least one document. 

4. The virtual signing room of claim 3, wherein the document management module further comprises a 
notification module for automatically notifying at least one user of a revision to the at least one document. 

AMENDED CLAIMS 

[received by the International Bureau on 13 September 2000 (13.09.00); 
original claims 1 and 4. amended; new claims 5-50 added; 
remaining claims unchanged(1 1 pages)] 
What is claimed is: 

1 . A computer-implemented virtual signing room for providing access to at least one document by a 
plurality of users from a plurality of locations, comprising: 

a document management module, for managing the at least one document; 
a party-to-document mapping module for specifying access rights to the at 
least one document; and 

a deal management module, coupled to the document management module, 
for maintaining a deal completion list containing document-related 
task items; 

wherein the document management module permits access to the at least one document responsive to 
the party-to-document mapping module indicating that a user has access rights to the at least one 
document. 

2. The virtual signing room of claim 1 , wherein the at least one document is encoded in an extensible 
markup language (XML) format. 

3. The virtual signing room of claim 1 , wherein the document management module further comprises an 
audit module for tracking revisions to the at least one document. 

4. The virtual signing room of claim 1 , wherein the document management module accepts and applies a 
revision to the at least one document; 

and wherein the document management module further comprises a notification module for automatically 
notifying at least one user of the revision. 

5. The virtual signing room of claim 4, wherein the notification module notifies the at least one user of the 
revision by displaying a dialog box responsive to the user accessing the virtual signing room. 

6. The virtual signing room of claim4, wherein the notification module notifies the at least one user of the 
revision by transmitting an electronic mail message to the user. 

7. The virtual signing room of claim 4, wherein the notification module retrieves an indicator specifying a 
notification medium for a portion of the document corresponding to the revision, and wherein the 
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notification module notifies the at least one user of the revision via the specified notification medium. 



8. The virtual signing room of claim 1, wherein the document management module accepts and applies a 
revision to the at least one document responsive the party-to-document mapping module indicating that a 
user has access rights permitting revision of the at least one document. 

9. The virtual signing room of claim '1 , wherein the party-to-document mapping module specifies access 
rights to a portion of at least one document. 

10. The virtual signing room of claim 9, wherein the document management module further accepts a 
revision to the portion of the at least one document responsive to the party-to-document mapping module 
indicating that a user has access rights permitting revision of the portion. 

1 1 . The virtual signing room of claim 1 , wherein the party-to-document mapping module specifies access 
rights to a first portion of a document and different access rights to a second portion of the document. 

12. The virtual signing room of claim 1, wherein the party-to-document mapping module comprises: 
a role identifier for defining a signing role for each of at least one user; and 

a map, coupled to the role identifier, for associating each signing role with at 
least one document. 

13. The virtual signing room of claim 12, wherein the role identifier comprises an authenticator for 
authenticating the identity of the at least one user, and for verifying the authority of the user to sign the 
document. 

14. The virtual signing room of claim 13, wherein the authenticator authenticates the identity of the user by 
public key cryptography. 

15. The virtual signing room of claim 13, further comprising: 

a smartcard reader, coupled to the authenticator, for reading a private key 
from a smartcard provided by the at least one user; 

and wherein the authenticator authenticates the identity of the user by validating the private key. 

16. The virtual signing room of claim 13, wherein the authenticator authenticates the identity of the user by 
receiving and validating biometric data of the user. 

17. The virtual signing room of claim 13, wherein the authenticator authenticates the identity of the user by 
receiving a passcode from the user and validating the received passcode. 

18. The virtual signing room of claim 12, wherein the role identifier receives input from a user specifying a 
signing role. 

19. The virtual signing room of claim 12, wherein the role identifier retrieves data from a stored cookie 
specifying a signing role. 

20. The virtual signing room of claim 12, wherein the party-to-document mapping module further retrieves 
a list of documents available for signing by the at least one user, based on the defined signing role. 

21 . The virtual signing room of claim 20, further comprising: 

a parser, coupled to the role identifier, for identifying at least one portion of the at least one document, to 
be signed by the at least one user; 

and wherein the party-to-document mapping module retrieves the list of documents available responsive 
to the identification by the parser. 

22. The virtual signing room of claim 1 , wherein the deal completion list comprises document-related task 
items including at least one selected from the group consisting of: 

at least one signature to be applied to a document; 

at least one data item to be provided; 

a deadline date for applying a signature to a document; and 

a signing sequence for a document. 

23. The virtual signing room of claim 1 , wherein the deal management module further comprises a next 
step module for monitoring a current status and next step specified by the deal completion list. 
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24. The virtual signing room of claim 23, wherein the deal management module updates the deal 
completion list responsive to at least one selected from the group consisting of: 

application of a signature to a document; 
revision of a document; 
deletion of a document; and 

creation of a document.^ i\. ■■• ..; .*>;;■• s .v.-.- •'" •:-\'- ! .. : . *i - 

25. The virtual signing room of claim 1, wherein the virtual signing room is accessible to at least one of the 
users over a network. 

26. A computer-implemented collaborative document editing system, comprising: 
a document management module, for managing at least one document; 

an input device, for receiving user input specifying at least one revision to the 
at least one document; 

a storage device, coupled to the document management module, for storing 
revision privileges for at least one user; 

a party-to-document mapping module, coupled to the storage device, for 

retrieving revision privileges from the storage device; 

a revision module, coupled to the input device, to the document management 

module, and to the party-to-document mapping module, for, 

responsive to the revision privileges permitting the user to edit the 

document, modifying the document according to the specified 

revision; and 

an audit module, coupled to the revision module, for, responsive to the 
revision privileges permitting the user to edit the document, tracking 
the specified revision to the document. 

27. The system of claim 26, wherein the storage device stores revision privileges corresponding to at least 
a portion of the at least one document. 

28. The system of claim 26, further comprising a notification module, coupled to the audit module, for 
automatically notifying at least one user of a revision to the at least one document. 

29. The system of claim 26, wherein the input device receives user input from a remote user over a 
network. 

30. The system of claim 26, wherein the party-to-document mapping module comprises: 
a role identifier for defining a role for each of at least one user; and 

a map, coupled to the role identifier, for associating each role with at least one 
document; 

and wherein each retrieved revision privilege corresponds to least one role. 

31. The system of claim 30, wherein the role identifier comprises an authenticator for authenticating the 
identity of the at least one user, and for verifying the authority of the user to edit the document. 

32. The system of claim 31, wherein the authenticator authenticates the identity of the user by public key 
cryptography. 

33. The system of claim 31 , further comprising: 

a smartcard reader, coupled to the authenticator, for reading a private key 
from a smartcard provided by the at least one user; 

and wherein the authenticator authenticates the identity of the user by validating the private key. 

34. The system of claim 31, wherein the authenticator authenticates the identity of the user by receiving 
and validating biometric data of the user. 

35. The system of claim 31, wherein the authenticator authenticates the identity of the user by receiving a 
passcode from the user and validating the received passcode. 

36. The system of claim 26, wherein the party-to-document mapping module retrieves revision privileges 
for each of at least two portions of the document, and wherein the revision module modifies the document 
responsive to the revision privileges for a portion of the document corresponding to the specified revision 
permitting the user to edit the portion. 
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38. The system of claim 26, further comprising an output device, coupled to the party-to-document 
mapping module; 

wherein the party-to-document mapping module further retrieves viewing privileges for the at least one . 
".- . document!- . ». ^v-. ' ■ *:-.•• .■ , -;>., • ..' ... '.,v.. . . . ' V-' ' ■ 

. and wherein r 'responsive ; to the viewing, privileges for a document permitting, the user to view the 
document, the output device outputs the document. 

39. The system of claim 26, further comprising an output device, coupled to the party-to-document 
mapping module; 

wherein the party-to-document mapping module further retrieves viewing privileges for at least a portion of 
the at least one document; 

and wherein, responsive to the viewing privileges for a portion of a document permitting the user to view 
the portion, the output device outputs the portion. 

40. The system of claim 39, wherein each portion corresponds to a field. 

41. The system of claim 26, further comprising a check-in module, coupled to the document management 
module, for receiving at least one document from an off-line source. 

42. The system of claim 26, wherein the input device accepts input specifying privileges for at least one 
document. 

43. A computer-implemented method for collaborative document editing, comprising: 
storing revision privileges for at least one user; 

receiving user input specifying at least one revision to the at least one 
document; 

retrieving revision privileges; 

responsive to the revision privileges permitting the user to edit the document: 
modifying the document according to the specified revision; and 
tracking the specified revision to the document. 

44. The method of claim 43, further comprising notifying at least one user of a revision to the at least one 
document. 

45. The method of claim 43, further comprising: 
defining a role for each of at least one user; and 
associating each role with at least one document; 

and wherein each retrieved revision privilege corresponds to least one role. 

46. The method of claim 45, further comprising: 
authenticating the identity of the at least one user; and 
verifying the authority of the user to edit the document. 

47. A computer program product comprising a computer-usable medium having computer-readable code 
embodied therein for collaborative document editing, comprising: 

computer-readable program code configured to cause a computer to store 
revision privileges for at least one user; 

computer-readable program code configured to cause a computer to receive 
user input specifying at least one revision to the at least one document; 
computer-readable program code configured to cause a computer to retrieve 
revision privileges; 

computer-readable program code configured to cause a computer to, 
responsive to the revision privileges permitting the user to edit the 
document: 

modify the document according to the specified revision; and 
track the specified revision to the document. 

48. The computer program product of claim 47, further comprising computer-readable program code 
configured to cause a computer to notify at least one user of a revision to the at least one document. 

49. The computer program product of claim 47, further comprising: 
computer-readable program code configured to cause a computer to define a 
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role for each of at least one user; and 

computer-readable program code configured to cause a computer to associate 
each role with at least one document; 

and wherein each retrieved revision privilege corresponds to least one role. 

■. 50. The computer program product of daim 49j further comprising: 
computer-readable program code configured to cause a computer to 
authenticate the identity of the at least one user; and 

computer-readable program code configured to cause a computer to verify the authority of the user to edit 
the document. 

STATEMENT UNDER PCT ARTICLE19 (1) 

The above amendments to the Claims are being submitted in accordance with the 
Patent Cooperation Treaty Article19. 

The above-described amendments include the amendments made to the related U. S. case which is 
pending. 

The above-described amendments do not go beyond the disclosure of the international application as 
filed, and entry of these amendments is respectfully requested. 

Replacement sheets effecting the above-described amendments are being transmitted herewith. 
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